Method and System for a Flexible Dynamic Spectrum Arbitrage System

ABSTRACT

A server computing device may be configured to perform dynamic spectrum arbitrage (DSA) operations that include broadcasting a communication message that includes information advertising that a telecommunication resource in a first telecommunication network is available for allocation and use by wireless devices in a second telecommunication network, determining lease criteria parameters of a resource lease associated with the advertised telecommunication resource, determining network capability of the second telecommunication network, selecting one of a DSA Lite network configuration, DSA9 network configuration, and DSAX network configuration based on the determined network capability and determined lease criteria, determining configuration parameters for one or more nodes in each of the first and second telecommunication networks based on the selected network configuration, and sending the determined configuration parameters to components in each of the first and second networks.

RELATED APPLICATIONS

This application is a continuation of U.S. Non-Provisional applicationSer. No. 15/071,040 titled “Method and System for a Flexible DynamicSpectrum Arbitrage System” filed Mar. 15, 2016, which is a continuationin part of U.S. Non-Provisional application Ser. No. 14/948,903 titled“Interfacing between a Dynamic Spectrum Policy Controller and a DynamicSpectrum Controller” filed Nov. 23, 2015, and is continuation of U.S.Non-Provisional application Ser. No. 14/287,090 titled “InterfacingBetween a Dynamic Spectrum Policy Controller and a Dynamic SpectrumController” filed May 26, 2014, which claims the benefit of priority toU.S. Provisional Application No. 61/827,911 titled “Interfacing betweena Dynamic Spectrum Policy Controller and a Dynamic Spectrum Controller”filed May 28, 2013, the entire contents of all of which are herebyincorporated by reference.

BACKGROUND

With the ever increasing use of wireless communication devices foraccessing networks and downloading large files (e.g., video files),there is an increasing demand for radio frequency spectrum. Smart phoneusers complain about dropped calls, slow access to the Internet andsimilar problems which are due largely to too many devices trying toaccess finite RF bandwidth allocated to such services. Yet parts of theRF spectrum, such as the RF bands dedicated to emergency services (e.g.,police, fire and rescue, etc.), go largely unused due to thenon-continuous and episodic employment of such voice-radio communicationbands. Therefore, improved methods and solutions for dynamicallyallocating underutilized telecommunication resources (e.g., RF spectrum,etc.) of a first telecommunication network for access and use bywireless devices that subscribe to other networks will be beneficial tothe telecommunication networks, service providers, and to the consumersof telecommunication services.

SUMMARY

The various aspects include methods of performing DSAFlex operation indynamic spectrum arbitrage (DSA) system, the DSAFlex operationsincluding broadcasting a communication message that includes informationadvertising that a telecommunication resource in a firsttelecommunication network is available for allocation and use bywireless devices in a second telecommunication network, deter mininglease criteria parameters of a resource lease associated with theadvertised telecommunication resource, determining network capability ofthe second telecommunication network, selecting one of a DSA Litenetwork configuration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria, determining configuration parameters for one or morenodes in each of the first and second telecommunication networks basedon the selected network configuration, and sending the determinedconfiguration parameters to components in each of the first and secondnetworks.

In an aspect, selecting one of a DSA Lite network configuration, DSA9network configuration, and DSAX network configuration based on thedetermined network capability and determined lease criteria includesselecting the DSAX network configuration, and sending the determinedconfiguration parameters to components in each of the first and secondnetworks includes sending the determined configuration parameterdirectly to the components in the first and second networks. In afurther aspect, sending the determined configuration parameter directlyto the components in the first and second networks includes sendingconfiguration parameters to an eNodeB via an Xe interface, and sendingconfiguration parameters to an MME component via an Xm interface.

In a further aspect, selecting one of a DSA Lite network configuration,DSA9 network configuration, and DSAX network configuration based on thedetermined network capability and determined lease criteria includesselecting the DSA Lite network configuration or the DSA9 networkconfiguration, and sending the determined configuration parameters tocomponents in each of the first and second networks includes sending thedetermined configuration parameters to an O&M component in each of thefirst and second networks. In a further aspect, determiningconfiguration parameters for one or more nodes in each of the first andsecond telecommunication networks based on the selected networkconfiguration includes determining configuration parameters that match aspecific OEM format. In a further aspect, sending the determinedconfiguration parameters to components in each of the first and secondnetworks includes sending the parameters in the specific OEM format. Ina further aspect, the method may include dynamically selecting aninterface based on the determined network capability. In a furtheraspect, the method may include routing traffic to destination componentsbased on the network configuration of the second network.

In a further aspect, the method may include receiving in a dynamicspectrum controller (DSC) processor a list of resources that areavailable for bidding via a communication link to a dynamic spectrumpolicy controller (DPC) that includes a DPC processor, generating a bidrequest message that includes information suitable for bidding on aresource identified in the received list of resources, and sending thegenerated bid request message to the DPC via the communication link.

In a further aspect, the method may include starting by the DPCprocessor a bid timer, receiving in the DPC processor the bid requestmessage from the DSC via the communication link, determining whether thebid request message is valid, sending a bid accept message to the DSCvia the communication link in response to determining that the bid isvalid, determining whether the bid timer has expired, determiningwhether the DSC is a winner bidder that is to be allocated the resourcebased on information included in the bid request message in response todetermining that the bid request message is valid and that the bid timerhas expired, and sending a bid won message to the DSC via thecommunication link in response to determining that the DSC is the winnerbidder.

Further aspects may include server computing device that includes aprocessor configured with processor executable instructions to performoperations including broadcasting a communication message that includesinformation advertising that a telecommunication resource in a firsttelecommunication network is available for allocation and use bywireless devices in a second telecommunication network, determininglease criteria parameters of a resource lease associated with theadvertised telecommunication resource, determining network capability ofthe second telecommunication network, selecting one of a DSA Litenetwork configuration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria, determining configuration parameters for one or morenodes in each of the first and second telecommunication networks basedon the selected network configuration, and sending the determinedconfiguration parameters to components in each of the first and secondnetworks.

In an aspect, the processor may be configured with processor executableinstructions to perform operations such that selecting one of a DSA Litenetwork configuration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria includes selecting the DSAX network configuration, andsending the determined configuration parameters to components in each ofthe first and second networks includes sending the determinedconfiguration parameter directly to the components in the first andsecond networks. In a further aspect, the processor may be configuredwith processor executable instructions to perform operations such thatsending the determined configuration parameter directly to thecomponents in the first and second networks includes sendingconfiguration parameters to an eNodeB via an Xe interface, and sendingconfiguration parameters to an MME component via an Xm interface.

In a further aspect, the processor may be configured with processorexecutable instructions to perform operations such that selecting one ofa DSA Lite network configuration, DSA9 network configuration, and DSAXnetwork configuration based on the determined network capability anddetermined lease criteria includes selecting the DSA Lite networkconfiguration or the DSA9 network configuration, and sending thedetermined configuration parameters to components in each of the firstand second networks includes sending the determined configurationparameters to an O&M component in each of the first and second networks.In a further aspect, the processor may be configured with processorexecutable instructions to perform operations such that determiningconfiguration parameters for one or more nodes in each of the first andsecond telecommunication networks based on the selected networkconfiguration includes determining configuration parameters that match aspecific OEM format.

In a further aspect, the processor may be configured with processorexecutable instructions to perform operations such that sending thedetermined configuration parameters to components in each of the firstand second networks includes sending the parameters in the specific OEMformat. In a further aspect, the processor may be configured withprocessor executable instructions to perform operations furtherincluding dynamically selecting an interface based on the determinednetwork capability. In a further aspect, the processor may be configuredwith processor executable instructions to perform operations furtherincluding routing traffic to destination components based on the networkconfiguration of the second network. In a further aspect, the processormay be configured with processor executable instructions to performoperations further including receiving a list of resources that areavailable for bidding via a communication link to a dynamic spectrumpolicy controller (DPC) that includes a DPC processor, generating a bidrequest message that includes information suitable for bidding on aresource identified in the received list of resources, and sending thegenerated bid request message to the DPC via the communication link.

In a further aspect, the processor may be configured with processorexecutable instructions to perform operations further including startingby the DPC processor a bid timer, receiving in the DPC processor the bidrequest message from a DSC via the communication link, determiningwhether the bid request message is valid, sending a bid accept messageto the DSC via the communication link in response to determining thatthe bid is valid, determining whether the bid timer has expired,determining whether the DSC is a winner bidder that is to be allocatedthe resource based on information included in the bid request message inresponse to determining that the bid request message is valid and thatthe bid timer has expired, and sending a bid won message to the DSC viathe communication link in response to determining that the DSC is thewinner bidder.

Further aspects may include a non-transitory computer readable storagemedium having stored thereon processor-executable software instructionsconfigured to cause a processor to perform operations includingbroadcasting a communication message that includes informationadvertising that a telecommunication resource in a firsttelecommunication network is available for allocation and use bywireless devices in a second telecommunication network, determininglease criteria parameters of a resource lease associated with theadvertised telecommunication resource, determining network capability ofthe second telecommunication network, selecting one of a DSA Litenetwork configuration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria, determining configuration parameters for one or morenodes in each of the first and second telecommunication networks basedon the selected network configuration, and sending the determinedconfiguration parameters to components in each of the first and secondnetworks.

In an aspect, the stored processor-executable software instructions maybe configured to cause the mobile device processor to perform operationssuch that selecting one of a DSA Lite network configuration, DSA9network configuration, and DSAX network configuration based on thedetermined network capability and determined lease criteria includesselecting the DSAX network configuration, and sending the determinedconfiguration parameters to components in each of the first and secondnetworks includes sending the determined configuration parameterdirectly to the components in the first and second networks. In afurther aspect, the stored processor-executable software instructionsmay be configured to cause the mobile device processor to performoperations sending the determined configuration parameter directly tothe components in the first and second networks includes sendingconfiguration parameters to an eNodeB via an Xe interface, and sendingconfiguration parameters to an MME component via an Xm interface.

In a further aspect, the stored processor-executable softwareinstructions may be configured to cause the mobile device processor toperform operations such that selecting one of a DSA Lite networkconfiguration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria includes selecting the DSA Lite network configuration orthe DSA9 network configuration, and sending the determined configurationparameters to components in each of the first and second networksincludes sending the determined configuration parameters to an O&Mcomponent in each of the first and second networks. In a further aspect,the stored processor-executable software instructions may be configuredto cause the mobile device processor to perform operations such thatdetermining configuration parameters for one or more nodes in each ofthe first and second telecommunication networks based on the selectednetwork configuration includes determining configuration parameters thatmatch a specific OEM format.

In a further aspect, the stored processor-executable softwareinstructions may be configured to cause the mobile device processor toperform operations such that sending the determined configurationparameters to components in each of the first and second networksincludes sending the parameters in the specific OEM format. In a furtheraspect, the stored processor-executable software instructions may beconfigured to cause the mobile device processor to perform operationsfurther including dynamically selecting an interface based on thedetermined network capability. In a further aspect, the storedprocessor-executable software instructions may be configured to causethe mobile device processor to perform operations further includingrouting traffic to destination components based on the networkconfiguration of the second network. In a further aspect, the storedprocessor-executable software instructions may be configured to causethe mobile device processor to perform operations further includingreceiving a list of resources that are available for bidding via acommunication link to a dynamic spectrum policy controller (DPC) thatincludes a DPC processor, generating a bid request message that includesinformation suitable for bidding on a resource identified in thereceived list of resources, and sending the generated bid requestmessage to the DPC via the communication link.

In a further aspect, the stored processor-executable softwareinstructions may be configured to cause the mobile device processor toperform operations further including starting by the DPC processor a bidtimer, receiving in the DPC processor the bid request message from a DSCvia the communication link, determining whether the bid request messageis valid, sending a bid accept message to the DSC via the communicationlink in response to determining that the bid is valid, determiningwhether the bid timer has expired, determining whether the DSC is awinner bidder that is to be allocated the resource based on informationincluded in the bid request message in response to determining that thebid request message is valid and that the bid timer has expired, andsending a bid won message to the DSC via the communication link inresponse to determining that the DSC is the winner bidder.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and constitutepart of this specification, illustrate exemplary embodiments of theinvention, and, together with the general description given above andthe detailed description given below, serve to explain features of theinvention.

FIGS. 1A through 1E are system block diagrams illustrating variouslogical and functions components and communication links incommunication systems that may be used to implement the variousembodiments.

FIG. 2A is a process flow diagram illustrating a dynamic spectrumarbitrage (DSA) method of allocating resources from the perspective of adynamic spectrum policy controller (DPC) in accordance with anembodiment.

FIG. 2B is a message flow diagram illustrating message communicationsbetween components of a DSA communication system when allocatingresources in accordance with an embodiment.

FIGS. 3 through 7 are process flow diagrams illustrating an embodimentDSA method of allocating and accessing resources in a communicationsystem that includes a DPC, two dynamic spectrum controllers (DSCs), anda wireless device.

FIGS. 8A through 8C are message flow diagrams illustrating an embodimentdynamic spectrum arbitrage application part (DSAAP) registration method.FIGS. 9A and 9B are message flow diagrams illustrating an embodimentDSAAP advertizing method.

FIGS. 10A and 10B are message flow diagrams illustrating an embodimentDSAAP method for communicating a list of available resources.

FIGS. 11A and 11B are message flow diagrams illustrating an embodimentDSAAP bidding method.

FIGS. 12A through 12D are message flow diagrams illustrating anembodiment DSAAP notification method for informing participatingnetworks of the results of the bidding operations.

FIGS. 13A and 13B are message flow diagrams illustrating an embodimentDSAAP purchase method for immediately (or near immediately) purchasing aresource.

FIGS. 14A and 14B are message flow diagrams illustrating an embodimentDSAAP allocation method for allocating resources in a lessor network foraccess and use by components in a lessee network.

FIGS. 15A and 15B are message flow diagrams illustrating an embodimentDSAAP backoff method of selectively handing over a wireless device froma lessor network back to the lessee's network (i.e. its home PLMN).

FIG. 16A is a message flow diagram illustrating an embodiment DSCinitiated DSAAP de-registration method for terminating DSA operations.

FIG. 16B is a message flow diagram illustrating an embodiment DPCinitiated DSAAP de-registration method for terminating DSA operations.

FIG. 17A is a message flow diagram illustrating a DSC initiated DSAAPerror indication method for reporting errors.

FIG. 17B is a message flow diagram illustrating a DPC initiated DSAAPerror indication method for reporting errors.

FIG. 18 is an activity diagram illustrating the operations andinformation flows between various components in a communication systemwhen performing a DSA resource update method.

FIG. 19 is a process flow diagram illustrating an embodiment DSA methodof allocating and de-allocating resources between different networks.

FIG. 20A is a process flow diagram illustrating a method of performingDSA operations in accordance with an embodiment.

FIG. 20B is a process flow diagram illustrating a method of performingDSA operations that include DSAFlex operations in accordance with anembodiment.

FIGS. 21A through 21C are activity diagrams illustrating variousoperations and information flows in systems configured to performDSAFlex operations in accordance with various embodiments.

FIG. 22 is a block diagram illustrating a system in which both thelessor and lessee networks are organized and/or configured to performDSAX operations in accordance with the various embodiments.

FIG. 23 is a block diagram illustrating a system in which both thelessor and lessee networks are organized and/or configured to performDSA9 operations in accordance with the various embodiments.

FIG. 24 is a block diagram illustrating a system in which the lessornetwork is organized/configured to perform DSAX operations and thelessee network is organized/configured to perform DSA9 operations inaccordance with an embodiment.

FIG. 25 is a block diagram illustrating a system in which both thelessor and lessee networks are organized/configured to perform DSA-Liteoperations in accordance with an embodiment.

FIG. 26 is a block diagram illustrating a system in which the lessornetwork is organized/configured to perform DSAX operations and thelessee network is organized/configured to perform DSA-Lite operations inaccordance with an embodiment.

FIG. 27 is a component block diagram of an example wireless devicesuitable for use with the various embodiments.

FIG. 28 is a component block diagram of a server suitable for use withan embodiment.

DETAILED DESCRIPTION

The various embodiments will be described in detail with reference tothe accompanying drawings. Wherever possible, the same reference numberswill be used throughout the drawings to refer to the same or like parts.References made to particular examples and implementations are forillustrative purposes, and are not intended to limit the scope of theinvention or the claims.

As used herein, the terms “wireless device,” “wireless device” and “userequipment (UE)” may be used interchangeably and refer to any one ofvarious cellular telephones, personal data assistants (PDA's), palm-topcomputers, laptop computers with wireless modems, wireless electronicmail receivers (e.g., the Blackberry® and Treo® devices), multimediaInternet enabled cellular telephones (e.g., the iPhone®), and similarpersonal electronic devices. A wireless device may include aprogrammable processor and memory. In a preferred embodiment, thewireless device is a cellular handheld device (e.g., a wireless device),which can communicate via a cellular telephone communications network.

As used in this application, the terms “component,” “module,” “engine,”“manager” are intended to include a computer-related entity, such as,but not limited to, hardware, firmware, a combination of hardware andsoftware, software, or software in execution, which are configured toperform particular operations or functions. For example, a component maybe, but is not limited to, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program, acomputer, a server, network hardware, etc. By way of illustration, bothan application running on a computing device and the computing devicemay be referred to as a component. One or more components may residewithin a process and/or thread of execution and a component may belocalized on one processor or core and/or distributed between two ormore processors or cores. In addition, these components may execute fromvarious non-transitory computer readable media having variousinstructions and/or data structures stored thereon.

A number of different cellular and mobile communication services andstandards are available or contemplated in the future, all of which mayimplement and benefit from the various embodiments. Such services andstandards include, e.g., third generation partnership project (3GPP),long term evolution (LTE) systems, third generation wireless mobilecommunication technology (3G), fourth generation wireless mobilecommunication technology (4G), global system for mobile communications(GSM), universal mobile telecommunications system (UMTS), 3GSM, generalpacket radio service (GPRS), code division multiple access (CDMA)systems (e.g., cdmaOne, CDMA2000™), enhanced data rates for GSMevolution (EDGE), advanced mobile phone system (AMPS), digital AMPS(IS-136/TDMA), evolution-data optimized (EV-DO), digital enhancedcordless telecommunications (DECT), Worldwide Interoperability forMicrowave Access (WiMAX), wireless local area network (WLAN), publicswitched telephone network (PSTN), Wi-Fi Protected Access I & II (WPA,WPA2), Bluetooth®, integrated digital enhanced network (iden), landmobile radio (LMR), and evolved universal terrestrial radio accessnetwork (E-UTRAN). Each of these technologies involves, for example, thetransmission and reception of voice, data, signaling and/or contentmessages. It should be understood that any references to terminologyand/or technical details related to an individual telecommunicationstandard or technology are for illustrative purposes only, and are notintended to limit the scope of the claims to a particular communicationsystem or technology unless specifically recited in the claim language.

The various embodiments include a dynamic spectrum arbitrage (DSA)system configured to dynamically manage the availability, allocation,access, and use of telecommunication resources, such as radio frequency(RF) spectrum and RF spectrum resources. The DSA system may includevarious DSA components, such as a dynamic spectrum policy controller(DPC) component and a dynamic spectrum controller (DSC) component. TheDPC component may be configured to manage the DSA operations andinteractions between two or more networks (e.g., between a lessornetwork and a lessee network), which often requires communicating with aDSC component in each of the participating networks. As part of theseDSA operations, the DSA components (e.g., DPC, DSC, etc.) may berequired to communicate frequently and/or transmit a large amount ofinformation. As such, the communications, interactions, andcommunication interfaces between these components may have a significantnegative impact on the efficiency and speed of the DSA system and theparticipating telecommunication networks.

The various embodiments include a dynamic spectrum arbitrage applicationpart (DSAAP) protocol and component configured to allow, facilitate,support, or augment communications between the DSA components (e.g.,DPC, DSC, eNodeB, etc.) so as to improve the efficiency and speed of theDSA system. In addition, the DSAAP protocol/component may be configuredto allow the DSA components to communicate specific information andperform operations that together provide various DSA functions thatimprove the efficiency and speed of the DSA system and participatingnetworks.

In various embodiments, all or portions of the DSAAP component may beincluded in a DPC component, a DSC component, an eNodeB component, in anindependent DSA component, or any combination thereof. The DSAAPcomponent may be implemented in hardware, software, or a combination ofhardware and software. In an embodiment, the DSAAP component may beconfigured to implement a DSAAP protocol, which may be defined over theXe, Xd, and/or X2 reference points. In various embodiments, the Xereference point between DSC and eNodeB may use the DSAAP protocol,TR-069 protocol, and/or TR-192 data model extensions to support listingavailable resources at the eNodeB and notifying the eNodeB of bid/buyconfirmations. The Xd reference point between DSC and DPC may use theDSAAP protocol for dynamic spectrum and resource arbitrage operations.The X2 interface/reference point between the eNodeBs may also use theDSAAP protocol to communicate information.

In various embodiments, the DSAAP component may be configured to allowan eNodeB to communicate with a DSC component (e.g., via the Xeinterface), with other eNodeBs (e.g., via an X2 interface), and withvarious other components (e.g., via the S1 interface). By allowing theeNodeB to communicate efficiently with these components, the DSAAPcomponent may further improves the efficiency and speed of the DSAsystem.

For example, in an embodiment, the DSA system may include an eNodeB thatis equipped with a DSC application protocol and congestion monitoring(DAPCM) module. The DAPCM module may be configured to monitor variousnetwork conditions (e.g., network congestion, resource usage, resourceavailability, etc.), generate reports based on the monitoring, and sendthe generated reports to a DSC component via the DSAAP. The DSC may beconfigured to receive and use such information to make better or moreinformed resource requests and/or to better identify the resources thatcould be made available for allocation.

As another example, in an embodiment, the DSC may include an eNodeBgeographic boundary management (EGBM) module configured to maintainrecords suitable for identifying geographical areas/boundariesassociated with various resources. The EGBM may be configured tocommunicate (e.g., via the DSAAP) this information to the eNodeB, whichmay receive and use such information to make better and more efficientuse of the allocated resources. For example, the eNodeB may use thegeographical information received from the DSC to better determine thegeographic regions (e.g., zones, cell sites, etc.) in which a wirelessdevice may use an allocated resource. Such communications also allow theDSA system to better allocate resources to a targeted geographic area,and to better allocate resources per user, per sector, per base station,per cell cluster, per license area, etc.

In various embodiments, the DSAAP component may be configured to allow,facilitate, support, or augment communications between the DSC componentand the DPC component so as to improve the efficiency and speed of theDSA system and telecommunication network. Such communications may allowthe DPC and/or DSC components to better pool resources across thedifferent networks, better monitor traffic and resource usage in thevarious networks, to more efficiently communicate bids and biddinginformation, to quickly and efficiently register and deregistercomponents, and better perform backoff operations. Such communicationsmay also improve the DSA resource auctioning operations by improving theperformance and efficiency of the procedures for bidding, generatinginvoices, advertizing resources, requesting resources, purchasingresources, validating bid credentials, etc.

In the various embodiments, the DSAAP component(s) may allow the variousDSA components (e.g., DSC, DPC, eNodeB, etc.) to communicate using theDSAAP protocol and to perform various DSAAP methods. For example, theDSAAP methods may be performed in a DSA system that includes a first DSCserver in a first telecommunication network (e.g., a lessee network), asecond DSC server in second telecommunication network (e.g., a lessornetwork), and a DPC server that is outside of the first and secondtelecommunication networks.

In various embodiments, the DSAAP component may be configured tofacilitate, support, or improve the DSA operations for bidding,resources allocation, and billing. Such DSAAP/DSA operations may includereceiving in a DSC processor a list of resources that are available forbidding (via a communication link to a DPC/DPC processor), generatingbid request message (e.g., DSC Bid Request message) that includesinformation suitable for bidding on a resource identified in thereceived list of resources, and sending the generated bid requestmessage to the DPC (via the communication link). The DSAAP/DSAoperations may also include the DPC processing starting a timer,receiving the bid request message (e.g., DSC Bid Request) from the DSCvia the communication link, determining whether the bid request messageis valid, and sending a bid accept message (DSC Bid Accept) to the DSCin response to determining that the bid is valid. The DPC processor maythen determine whether the bid timer has expired, determine whether theDSC is a winning bidder that is to be allocated the resource (i.e.,based on information included in the bid request message) in response todetermining that the bid request message is valid and that bid timer hasexpired. The DPC processor may send a bid won message to the DSC via thecommunication link in response to determining that the DSC is thewinning bidder. The DPC processor may then allocate the resource from alessor network for access and use by a lessee network associated withthe DSC.

In an embodiment, the DSAAP/DSA operations may include receiving in theDPC processor usage parameters and payment instructions from a componentin the lessor network, generating an invoice for the access and use ofthe allocated resource by the lessee network, and sending the generatedinvoice to the DSC. The DPC processor may send the payment instructionsand an invoice for to the use of the allocated resource by the lesseenetwork to the DSC via the communication link, receive paymentinformation from the DSC, and use the received payment information tosettle the invoice.

In an embodiment, the DSAAP/DSA operations may include resourceregistrations operations. For example, the DPC processor may beconfigured to receive a resource register request message (e.g., DSCResource Registration Request) from a second DSC in a lessor network,use the information included in the received resource register requestmessage to make a plurality of resources available for bidding or buyingvia a financial brokerage platform, and generate the list of resourcesto include the plurality of resources. The bid request message mayinclude a bid identifier information element (IE) that identifies aspecific resource for which the DSC bids, a network identifier IE thatidentifies a specific network that includes the resource for which theDSC bids, and a bid amount IE that identifies a monetary amount offeredfor the access and use of the resource for which the DSC bids. In anembodiment, determining whether the bid request message is valid mayinclude determining whether the monetary amount offered for the accessand use of the resource (i.e., in the bid request message) is equal toan asking price for that resources received from its correspondinglessor network.

The various embodiments may be implemented within a variety ofcommunication systems, examples of which are illustrated in FIGS. 1A-1E.With reference to FIG. 1A, wireless devices 102 may be configured totransmit and receive voice, data, and control signals to and from a basestation 111, which may be a base transceiver station (BTS), NodeB,eNodeB, etc. The base station 111 may communicate with an access gateway113, which may include one or more of a controller, a gateway, a servinggateway (S-GW), a packet data network gateway (PGW), an evolved packetdata gateway (ePDG), a packet data serving node (PDSN), a serving GPRSsupport node (SGSN), or any similar component or combinations of thefeatures/functions provided thereof. Since these structures are wellknown and/or discussed in detail further below, certain details havebeen omitted from FIG. 1A in order to focus the descriptions on the mostrelevant features.

The access gateway 113 may be any logical and/or functional componentthat serves as the primary point of entry and exit of wireless devicetraffic and/or connects the wireless devices 102 to their immediateservice provider and/or packet data networks (PDNs). The access gateway113 may forward the voice, data, and control signals to other networkcomponents as user data packets, provide connectivity to external packetdata networks, manage and store contexts (e.g. network internal routinginformation, etc.), and act as an anchor between different technologies(e.g., 3GPP and non-3GPP systems). The access gateway 113 may coordinatethe transmission and reception of data to and from the Internet 105, aswell as the transmission and reception of voice, data and controlinformation to and from an external service network 104, the Internet105, other base stations 111, and to wireless devices 102.

In various embodiments, the base stations 111 and/or access gateway 113may be coupled (e.g., via wired or wireless communication links) to adynamic spectrum arbitrage (DSA) system configured to dynamically managethe availability, allocation, access, and use of various networkresources (e.g., RF spectrum, RF spectrum resources, etc.). The DSAsystem is discussed in detail further below.

FIG. 1B illustrates that wireless devices 102 may be configured to sendand receive voice, data and control signals to and from the servicenetwork 104 (and ultimately the Internet 105) using a variety ofcommunication systems/technologies (e.g., GPRS, UMTS, LTE, cdmaOne,CDMA2000™), any or all of which may be supported by, or used toimplement, the various embodiments.

In the example illustrated in FIG. 1B, long term evolution (LTE) and/orevolved universal terrestrial radio access network (E-UTRAN) datatransmitted from a wireless device 102 is received by an eNodeB 116, andsent to a serving gateway (S-GW) 118 located within the core network120. The eNodeB 116 may send signaling/control information (e.g.,information pertaining to call setup, security, authentication, etc.) toa mobility management entity (MME) 130. The MME 130 may requestuser/subscription information from a home subscriber server (HSS) 132,communicate with other MME components, perform various administrativetasks (e.g., user authentication, enforcement of roaming restrictions,etc.), select a S-GW 118, and send authorization and administrativeinformation to the eNodeB 116 and/or S-GW 118. Upon receiving theauthorization information from the MME 130 (e.g., an authenticationcomplete indication, an identifier of a selected S-GW, etc.), the eNodeB116 may send data received from the wireless device 102 to a selectedS-GW 118. The S-GW 118 may store information about the received data(e.g., parameters of the IP bearer service, network internal routinginformation, etc.) and forward user data packets to a policy controlenforcement function (PCEF) and/or packet data network gateway (PGW)128.

FIG. 1B further illustrates that general packet radio service (GPRS)data transmitted from the wireless devices 102 may be received by a basetransceiver station (BTS) 106 and sent to a base station controller(BSC) and/or packet control unit (PCU) component (BSC/PCU) 108. Codedivision multiple access (CDMA) data transmitted from a wireless device102 may be received by a base transceiver station 106 and sent to a basestation controller (BSC) and/or packet control function (PCF) component(BSC/PCF) 110. Universal mobile telecommunications system (UMTS) datatransmitted from a wireless device 102 may be received by a NodeB 112and sent to a radio network controller (RNC) 114.

The BSC/PCU 108, BSC/PCF 110, and RNC 114 components may process theGPRS, CDMA, and UMTS data, respectively, and send the processed data toa component within the core network 120. More specifically, the BSC/PCU108 and RNC 114 units may send the processed data to a serving GPRSsupport node (SGSN) 122, and the BSC/PCF 110 may send the processed datato a packet data serving node (PDSN) and/or high rate packet dataserving gateway (HS-GW) component (PDSN/HS-GW) 126. The PDSN/HS-GW 126may act as a connection point between the radio access network and theIP based PCEF/PGW 128. The SGSN 122 may be responsible for routing thedata within a particular geographical service area, and send signaling(control plane) information (e.g., information pertaining to call setup,security, authentication, etc.) to an MME 130. The MME 130 may requestuser and subscription information from a home subscriber server (HSS)132, perform various administrative tasks (e.g., user authentication,enforcement of roaming restrictions, etc.), select a S-GW 118, and sendadministrative and/or authorization information to the SGSN 122.

The SGSN 122 may send the GPRS/UMTS data to a selected S-GW 118 inresponse to receiving authorization information from the MME 130. TheS-GW 118 may store information about the data (e.g., parameters of theIP bearer service, network internal routing information, etc.) andforward user data packets to the PCEF/PGW 128. The PCEF/PGW 128 may sendsignaling information (control plane) to a policy control rules function(PCRF) 134. The PCRF 134 may access subscriber databases, create a setof policy rules and performs other specialized functions (e.g.,interacts with online/offline charging systems, application functions,etc.). The PCRF 134 may then send the policy rules to the PCEF/PGW 128for enforcement. The PCEF/PGW 128 may implement the policy rules tocontrol the bandwidth, the quality of service (QoS), the characteristicsof the data, and the services being communicated between the servicenetwork 104 and the end users.

In the various embodiments, any or all of the components discussed above(e.g., components 102-134) may be coupled to, or included in, a DSAsystem configured to dynamically manage the availability, allocation,access, and use of telecommunication resources.

FIG. 1C illustrates various logical components and communication linksin an embodiment system 100 that includes an DSA system 142 and aevolved universal terrestrial radio access network (E-UTRAN) 140. In theexample illustrated in FIG. 1C, the DSA system 142 includes a dynamicspectrum controller (DSC) 144 component and a dynamic spectrum policycontroller (DPC) 146 component. The E-UTRAN 140 includes a plurality ofinterconnected eNodeBs 116 coupled to the core network 120 (e.g., via aconnection to an MME, S-GW, etc.).

In various embodiments, the DSC 144 may be included in or coupled to theE-UTRAN 140, either as part of its core network 120 or outside of thecore network 120. In an embodiment, the DSC 144 may be coupled directly(e.g., via wired or wireless communication links) to one or more eNodeBs116.

The eNodeBs 116 may be configured to communicate with the DSC 144 viathe Xe interface/reference point. In various embodiments, the Xereference point between DSC and eNodeB 116 may use the DSAAP protocol,TR-069 protocol, and/or TR-192 data model extensions to support listingavailable resources at the eNodeB 116 and notifying the eNodeB 116 ofbid/buy confirmations. The DSC 144 may be configured to communicate withthe DPC 146 via the Xd interface/reference point. The Xd reference pointbetween DSC and DPC may use the DSAAP protocol for dynamic spectrum andresource arbitrage operations. The eNodeBs 116 may be interconnected,and configured to communicate via an X2 interface/reference point, whichmay also use the DSAAP protocol to communicate information. The eNodeBs116 may be configured to communicate with components in the core network120 via the S1 interface. For example, the eNodeBs 116 may be connectedto an MME 130 via the S1-MME interface and to a S-GW 118 via the S1-Uinterface. The S1 interface may support a many-to-many relation betweenthe MMEs 130, S-GWs 118, and eNodeBs 116. In embodiment, the DPC and/orDSC component may also be configured to communicate with a HSS 132component.

The eNodeBs 116 may be configured to provide user plane (e.g., PDCP,RLC, MAC, PHY) and control plane (RRC) protocol terminations towards thewireless device 102. That is, the eNodeBs 116 may act as a bridge (e.g.,layer 2 bridge) between the wireless devices 102 and the core network120 by serving as the termination point of all radio protocols towardsthe wireless devices 102, and relaying voice (e.g., VoIP, etc.), data,and control signals to network components in the core network 120. TheeNodeBs 116 may also be configured to perform various radio resourcemanagement operations, such as controlling the usage of radiointerfaces, allocating resources based on requests, prioritizing andscheduling traffic according to various quality of service (QoS)requirements, monitoring the usage of network resources, etc. Inaddition, the eNodeBs 116 may be configured to collect radio signallevel measurements, analyze the collected radio signal levelmeasurements, and handover wireless devices 102 (or connections to themobile devices) to another base station (e.g., a second eNodeB) based onthe results of the analysis.

The DSC 144 and DPC 146 may be functional components configured tomanage the dynamic spectrum arbitrage process for sharing radiofrequency and other network resources between different E-UTRANs 140.For example, the DPC 146 component may be configured to manage the DSAoperations and interactions between multiple E-UTRAN networks bycommunicating with DSCs 144 in the E-UTRAN network.

FIG. 1D illustrates various logical and functional components that maybe included in a communication system 101 that suitable for use inperforming DSA operations in accordance with various embodiments. In theexample illustrated in FIG. 1D, the communication system 101 includes aneNodeB 116, a DSC 144, a DPC 146, an MME 130, a S-GW 118, and a PGW 128.

The eNodeB 116 may include a DSC application protocol and congestionmonitoring module 150, an inter-cell radio resource management (RRM)module 151, a radio bearer (RB) control module 152, a connectionmobility control module 153, a radio admission control module 154, aneNodeB measurement configuration and provision module 155, and a dynamicresource allocation module 156. Each of these modules 150-156 may beimplemented in hardware, in software, or in a combination of hardwareand software.

In addition, the eNodeB 116 may include various protocol layers,including a radio resource control (RRC) layer 157, a packet dataconvergence protocol (PDCP) layer 158, a radio link control (RLC) layer159, a medium access control (MAC) layer 160, and a physical (PHY) layer161. In each of these protocol layers, various hardware and/or softwarecomponents may implement functionality that is commensurate withresponsibilities assigned to that layer. For example, data streams maybe received in the physical layer 161, which may include a radioreceiver, buffers, and processing components that perform the operationsof demodulating, recognizing symbols within the radio frequency (RF)signal, and performing other operations for extracting raw data from thereceived RF signal.

The DSC 144 may include an eNodeB geographic boundary management module162, an eNodeB resource and congestion management module 163, a streamcontrol transmission protocol (SCTP) module 164, a Layer-2 (L2) buffermodule 165, and a Layer-1 (L1) buffer module 166. The DPC 146 mayinclude an eNodeB resource bid management module 167, an inter-DSCcommunication module 168, SCTP/DIAMETER module 169, an L2 buffer module170, and a L1 buffer module 171. The MME 130 may include a non-accessstratum (NAS) security module 172, and idle state mobility handlingmodule 173, and an evolved packet system (EPS) bearer control module174. The S-GW 118 may include a mobility anchoring module 176. The PGW128 may include a UE IP address allocation module 178 and a packetfiltering module 179. Each of these modules 162-179 may be implementedin hardware, in software, or in a combination of hardware and software.

The eNodeB 116 may be configured to communicate with the S-GW 118 and/orMME 130 via the S1 interface/protocol. The eNodeB 116 may also beconfigured to communicate with the DSC 144 via the Xeinterface/protocol. The DSC 144 may be configured to communicate withthe DPC 146 via the Xd interface/protocol.

The eNodeB 116 may be configured to perform various operations (e.g.,via modules/layers 150-161) to provide various functions, includingfunctions for radio resource management, such as radio bearer control,radio admission control, connection mobility control, dynamic allocationof resources to wireless devices 102 in both uplink and downlink(scheduling), etc. These functions may also include IP headercompression and encryption of user data stream, selection of an MME atUE attachment when no routing to an MME 130 can be determined from theinformation provided by the UE, routing of user plane data towards S-GW118, scheduling and transmission of paging messages (originated from theMME), scheduling and transmission of broadcast information (originatedfrom the MME), measurement and measurement reporting configuration formobility and scheduling, scheduling and transmission of public warningsystem (e.g., earthquake and tsunami warning system, commercial mobilealert service, etc.) messages (originated from the MME), closedsubscriber group (CSG) handling, and transport level packet marking inthe uplink. In an embodiment, the eNodeB 116 may be a donor eNodeB(DeNB) that is configured to perform various operations to provideadditional functions, such as an S1/X2 proxy functionality, S11termination, and/or S-GW/PGW functionality for supporting relay nodes(RNs).

The MME 130 may be configured to perform various operations (e.g., viamodules 172-175) to provide various functions, including non-accessstratum (NAS) signaling, NAS signaling security, access stratum (AS)security control, inter-CN node signaling for mobility between 3GPPaccess networks, idle mode UE reach-ability (including control andexecution of paging retransmission), tracking area list management(e.g., for a wireless device in idle and active mode), PGW and S-GWselection, MME selection for handovers with MME change, SGSN selectionfor handovers to 2G or 3G 3GPP access networks, roaming, authentication,bearer management functions including dedicated bearer establishment,support for public warning system (e.g., earthquake and tsunami warningsystem, commercial mobile alert service, etc.) message transmission, andperforming paging optimization. The MME module may also communicatevarious device state and attach/detach status information to the DSC. Inan embodiment, the MME 130 may be configured to not filter pagingmassages based on the CSG IDs towards macro eNodeBs.

The S-GW 118 may be configured to perform various operations (e.g., viamodule 176) to provide various functions, including mobility anchoring(e.g., for inter-3GPP mobility), serving as a local mobility anchorpoint for inter-eNodeB handovers, E-UTRAN idle mode downlink packetbuffering, initiation of network triggered service request procedures,lawful interception, packet routing and forwarding, transport levelpacket marking in the uplink (UL) and the downlink (DL), accounting onuser and QoS class identifier (QCI) granularity for inter-operatorcharging, uplink (UL) and the downlink (DL) charging (e.g., per device,PDN, and/or QCI), etc.

The PGW 128 may be configured to perform various operations (e.g., viamodules 178-179) to provide various functions, including per-user basedpacket filtering (by e.g. deep packet inspection), lawful interception,UE IP address allocation, transport level packet marking in the uplinkand the downlink, UL and DL service level charging, gating and rateenforcement, DL rate enforcement based on APN-aggregate maximum bit rate(AMBR), etc.

The DSC 144 may be configured to perform various operations (e.g., viamodules 162-166) to provide various functions, including managingresource arbitration operations within a network (e.g., Public LandMobile Network (PLMN)), tracking network resource listings, trackingcurrent bids in progress, tracking executed bids, and tracking bidspecific closed subscriber group (CSG) identifiers (CSG-IDs) formobility management of lessee wireless devices 102 in lessor networks.The DSC 144 may be configured to handover wireless devices 102 fromlessee network to lessor network (i.e., perform handins), and handoverwireless devices 102 from lessor network back to lessee network (i.e.,perform backoff).

The DSC 144 may also be configured to track congestion states ofeNodeBs, select target eNodeBs for handovers, and manage traffic onlessor eNodeBs. The DSC 144 may be configured to offload users based onconfigured policies (e.g. offload lower priority users, offload higherpriority users, offload users with specific QoS, etc.) from lesseenetworks to other less loaded eNodeBs 116 within a lessor network. TheDSC 144 may also perform backoff operations to handover a wirelessdevice 102 from lessor network back to the lessee network. The DSC 144may also be configured to monitor, manage, and/or maintain historiccongestion information that is collected or received from one or moreeNodeBs in the system.

The DPC 146 may be configured to perform various operations (e.g., viamodules 167-171) to provide various functions, including functioning asa resource arbitrage broker between the DSCs 144 of lessor and lesseenetworks (e.g., PLMNs), listing resources from various lessor networksfor auction, and managing the auction process. The DPC 146 may beconfigured to send notifications of outbid, bid win, bid cancel and bidwithdrawal and bid expiry to DSCs 144, install bid specific chargingrules in the online and/or offline charging systems of lessee and lessornetworks, and coordinate resource usage between DSCs 144 by acting asgateway between lessee and lessor DSCs 144.

FIG. 1E illustrates network components and information flows in anexample communication system 103 that includes two E-UTRANs 140 a, 140 binterconnected by a DPC 146 configured to manage DSA operations andinteractions. In the example illustrated in FIG. 1E, each E-UTRAN 140 a,140 b includes an eNodeB 116 a, 116 b that is outside of its corenetwork 120 a, 120 b, and a DSC 144 a, 144 b that is inside of the corenetwork 120 a, 120 b.

The DSCs 144 a, 144 b may be configured to communicate with the DPC 146via Xd interface. The DSCs 144 a, 144 b may also be connected, directlyor indirectly, to various network components in their respective corenetworks 120 a, 120 b, such as a PCRF 134, HSS 132 and a PCEF/PGW 128(not illustrated in FIG. 1E). In an embodiment, one or more of the DSCs144 a, 144 b may be connected directly to one or more of the eNodeBs 116a, 116 b.

In addition to the above-mentioned connections and communication links,the system 103 may include additional connections/links to accommodatedata flows and communications between components in different E-UTRANs(e.g., E-UTRANS 140 a and 140 b). For example, the system 103 mayinclude a connection/communication link between an eNodeB 116 b in thesecond E-UTRAN 140 b to an S-GW 118 in the first E-UTRAN 140 a. Asanother example, the system 103 may include a connection/communicationlink between a S-GW 118 in the second E-UTRAN 140 b to a PGW 128 in thefirst E-UTRAN 140 a. To focus the discussion of the relevantembodiments, these additional components, connections, and communicationlinks are not illustrated in FIG. 1E.

As is discussed in detail further below, the DSCs 144 a, 144 b may beconfigured to send information regarding the availability of spectrumresources (e.g., information received from an eNodeB, PCRF, PCEF, PGW,etc.) to the DPC 146. This information may include data relating tocurrent and expected future usage and/or capacity of each network orsub-network. The DPC 146 may be configured to receive and use suchinformation to intelligently allocate, transfer, manage, coordinate, orlease the available resources of the first E-UTRAN 140 a to the secondE-UTRAN 140 b, and vice versa.

For example, the DPC 146 may be configured to coordinate the allocationof spectrum resources to the second E-UTRAN 140 b (i.e., lessee network)from the E-UTRAN 140 a (i.e., lessor network) as part of the dynamicspectrum arbitrage operations. Such operations may allow a wirelessdevice 102 that is wirelessly connected to the eNodeB 116 b in thesecond E-UTRAN 140 b via a communication link 143 to be handed off to aneNodeB 116 a in the first E-UTRAN 140 a so that it may use the allocatedspectrum resources of the first E-UTRAN 140 a. As part of this handoffprocedure, the wireless device 102 may establish a new connection 141 tothe eNodeB 116 a in the first E-UTRAN 140 a, terminate the wirelessconnection 143 to the original eNodeB 116 b, and use the allocatedresources of the first E-UTRAN 140 a as if they are included in thesecond E-UTRAN 140 b. The DSA operations may be performed so that thefirst DSC 144 a is a lessor DSC for a first resource/period of time, anda lessee DSC for a second resource or another period of time.

In an embodiment, the DSA and/or handoff operations may be performed sothat the wireless device 102 maintains a data connection to (or a dataconnection that is managed by) the original network after it is handedoff. For example, DSA and/or handoff operations may be performed so thatthe wireless device 102 maintains a dataflow connection to a PGW 128 inthe second E-UTRAN 140 b after being handed off to the eNodeB 116 a inthe first E-UTRAN 140 a.

FIG. 2A illustrates an example DSA method 200 of allocating resources inaccordance with an embodiment. Method 200 may be performed by aprocessing core in a DPC 146 component (e.g., server computing device,etc.).

In block 202, the DPC 146 may establish a first communication link to afirst DSC 144 a in a first communication network (e.g., E-UTRAN, etc.).In block 204, the DPC 146 may establish a second communication link to asecond DSC 144 b in a second communication network. In block 206, theDPC 146 may determine whether radio frequency (RF) spectrum resourcesare available for allocation within the second communication network.This may be accomplished by using the DSAAP protocol to communicate witha DSC 144 in the second communication network via the secondcommunication link, which may be a wired or wireless communication link.In block 208, the DPC 146 may determine the amount of RF spectrumresources that are available for allocation. In block 210, the DPC 146may perform various operations to allocate all or a portion of theavailable RF resources of the second communication network for accessand use by wireless devices 102 in the first communication network.

In block 212, the DPC 146 may send a communication message to the firstDSC 144 a (e.g., by using the DSAAP protocol) to inform the firstcommunication network that the use of the allocated RF spectrumresources may begin. In block 214, the DPC 146 may record a transactionin a transaction database identifying an amount of RF spectrum resourcesallocated for use by the first communication network.

In block 216, the DPC 146 may receive a communication message from thesecond DSC 144 b that includes information indicating that the allocatedresources have been consumed and/or requesting that the allocatedresources be released. In block 218, the DPC 146 may send a resourceconsumed/release message to the first DSC 144 a to cause the firstnetwork to terminate its use of the allocated resources.

FIG. 2B illustrates example information flows between a DPC 146 and aplurality of DSCs 144 a-d when performing another embodiment DSA method250 to allocate resources. In the description below, the DSA method 250is discussed from the perspective of the DPC 146 component, and may beperformed by a processing core in the DPC 146. However, it should beunderstood that the DSA method 250 may be performed by processing coresin a DPC 146 component, processing cores in DSC 144 a-d components, or acombination thereof. In addition, it should be understood that all theinteractions and communications between the DPC 146 and the othercomponents may be accomplished by DSAAP components and/or using theDSAAP protocol. As such, all such interactions and communications may beincluded in the DSAAP protocol.

In operation 252, a processing core in a DPC 146 component may receive a“request for resources” communication message from a first DSC 144 acomponent in a first network (e.g., E-UTRAN, etc.). It should beunderstood that the “request for resources” communication message andall other communication messages discussed in this application may beDSAAP messages.

The “request for resources” communication message may includeinformation suitable for informing the DPC 146 that the first network isinterested in purchasing, leasing, accessing, and/or using resourcesfrom other networks. The “request for resources” communication messagemay also include information suitable for identifying the types and/oramounts of resources (e.g., RF spectrum resources, etc.) that arerequested by the first network, the types and capabilities of thewireless devices 102 to which the requested resources will be allocated,and other similar information.

In operations 254, 256, and 258 the DPC 146 may generate and send a“resource inquiry” communication message to each of a second DSC 144 bcomponent in a second network, a third DSC 144 c component in a thirdnetwork, and a fourth DSC 144 d component in a fourth network,respectively. The DPC 146 may be configured to generate the “resourceinquiry” communication messages to include various component, device,and resource requirements, criteria, and information. For example, theDPC 146 may generate a “resource inquiry” communication message toinclude information identifying the types, capabilities, and geographiccriteria of user wireless devices 102 in the first network (and othernetworks) to which resources are to be allocated. The geographiccriteria may include a geographic location, a geographic polygon, and/orlicense area for a user wireless device 102 to which resources will beallocated.

In operations 260 and 262, the DPC 146 may receive “resource inquiryresponse” communication messages from the second and third DSCs 144 b,144 c. These “resource inquiry response” communication messages mayinclude information identifying the availability of excess resourcesthat comply with the requirements/criteria included in the resourceinquiry messages. In operation 264, the DPC 146 may receive another“resource inquiry response” communication message from the fourth DSC144 d. This “resource inquiry response” communication messages mayinclude information indicating that the fourth network does not includeresources that meet the requested requirements/criteria.

In an embodiment, as part of operations 260-264, the DPC 146 may updatea database record to identify the second and third networks as havingresources available for allocation and/or to identify the fourth networkas not including such resources.

In operation 266, the DPC 146 may generate and send a “resourceavailability” communication message to a plurality of DSCs in aplurality of networks, including the first DSC 144 a in the firstnetwork. The DPC 146 may be configured to generate the “resourceavailability” communication message to include information that issuitable for informing the networks that resources are available forallocation. In an embodiment, the DPC 146 may be configured to informthe networks that resources are available for allocation by broadcastinga communication signal that includes information suitable for informingthe networks that resources are available for allocation via auctionand/or an auction start time for the auction.

In operation 268, the DPC 146 may receive a “resource reservationrequest” communication message from the first DSC 144 a. The received“resource reservation request” communication message may includeinformation suitable for informing the DPC 146 that the first networkintends to participate in the auction and/or bid on at least a portionof the available resources.

In operations 270 and 272, the DPC 146 may send the “resourcereservation request” communication message to the second and third DSCs144 b, 144 c, respectively. The “resource reservation request”communication message may include information suitable for causing thesecond and third DSCs 144 b, 144 c to reserve all or a portion of theiravailable resources for allocation and use by other networks.

In operations 274 and 276, the DPC 146 may receive a “resourcereservation response” communication message from each of the second andthird DSCs 144 b, 144 c. The “resource reservation response” messagesmay include information suitable for informing the DPC 146 that therequested resources that have been reserved and/or information suitablefor identifying the reserved resources.

Optionally, in operation block 278, the DPC 146 may pool the reservedresources for allocation and use by wireless devices 102 in othernetworks (e.g., the first network). For example, the DPC 146 may combinea block of spectrum reserved in the second network with a block ofspectrum reserved in the third network. As another example, the DPC 146may pool the resources available in the first and fourth channels of ablock of spectrum reserved in the second network.

In operation 280, the DPC 146 may receive “resource bid” communicationmessages from a plurality of networks, including from the first DSC 144a in the first network. Each “resource bid” communication message mayinclude a bid or offer for accessing, using, leasing, and/or purchasinga resource, as well as other related bid information (e.g., price,requested allocation/access methods, etc.). As part of operation 280,the DPC 146 may determine whether the received resource bids comply withthe policies and rules of the DSA system and/or with requirements setforth by the networks offering the resources for allocation (e.g., meetthe minimum asking price, etc.).

In operation 282, the DPC 146 may accept the bid/offer from the firstnetwork in response to determining that the resource bid received fromthe first network complies with the policies/rules of the DSA system andwith requirements set forth by the resource offering network (e.g.,offers a monetary amount for the use of all or a portion of theresources in the pool of available resources that is greater than orequal to a minimum amount specified by the second network). Also inoperation 282, the DPC 146 may generate and send a “bid acceptance”communication message to the first DSC 144 a.

In operation 284, the DPC 146 may allocate the resources of the secondnetwork for access and used by wireless devices 102 in the first networkby sending an “assign resources request” communication message to thesecond DSC 144 b. That is, in operation 284, the DPC may determine thatthe portion of the resources (e.g., in the pool of available resources)won by the first DSC 144 a are fully available via the second network,and in response, only send the assign resources request message to thesecond network.

In operation 286, the DPC 146 may receive a “resources allocated”communication message from the second DSC 144 b. In operation 288, theDPC 146 may send the “resources allocated” communication message to thefirst DSC 144 a to inform the first network that the resources have beenallocated for access and used by its wireless devices 102 and/or thatthe use of the allocated resources may begin. In operation block 290,the DPC 146 may record a transaction in a transaction databaseidentifying these resources as being allocated for access and use by thefirst network.

In operation 292, the DPC 146 may receive a “release resources”communication message from the second DSC 144 b that includesinformation indicating that the allocated resources have been consumedand/or information suitable for requesting that the allocated resourcesbe released. In operation 294, the DPC 146 may send a resourceconsumed/release message to the first DSC 144 a to cause the firstnetwork to terminate its use of the allocated resources.

FIGS. 3-7 illustrate an embodiment DSA method 300 for allocating andaccessing resources in a communication system that includes a DPC 146component, two DSC 144 a, 144 b components, and wireless devices 102.All or portions of DSA method 300 may be performed by processing coresin a DPC 146, DSCs 144 a-b, and/or wireless device 102. In the variousembodiments, any of all of the interactions and communications betweenthe components 146, 144 a, 144 b, and 102 may be accomplished orfacilitated by DSAAP components and/or using the DSAAP protocol. Assuch, all such interactions and communications may be included in theDSAAP protocol.

With reference to FIG. 3, in block 302, a first DSC 144 a in a firstnetwork may monitor user traffic (e.g., call and data traffic, etc.) ascompared to the total spectrum resources available to the first network.In block 304, the first DSC 144 a may generate a resource status reportbased on a result of its monitoring, record/store the resource statusreport in memory, and send a resource status report to the DPC 146 via aresources status report communication message. In determination block306, the first DSC 144 a may determine, based on the received resourcestatus reports, whether additional resources are required (and/orwhether there is a high probability that additional resources will berequired in the near future) to provide adequate service to the existingwireless devices 102 in the first network. In response to determiningthat additional resources are required (i.e., determination block306=“Yes”), in block 308, the first DSC 144 a may send a “request forresources” communication message to the DPC 146. In response todetermining that additional resources are not required (i.e.,determination block 306=“No”), the first DSC 144 a may continuemonitoring user traffic and/or perform other DSC operations in block302.

In block 310, a second DSC 144 b in a second network may monitor usertraffic as compared to the total spectrum resources available to thesecond network, generate resource status reports, and/or perform any orall of the DSC operations discussed in this application. Indetermination block 312, the second DSC 144 b may determine whetherthere is an excess amount of resources available in the second network.In response to determining that there are no excess resources availablein the second network (i.e., determination block 312=“No”), in block310, the second DSC 144 b may continue monitoring user traffic and/orperforming other DSC operations.

In response to determining that there is an excess amount of resourcesavailable in the second network (i.e., determination block 312=“Yes”),in block 314, the second DSC 144 b may mark, designate, or allocate allor portions of its excess resources for access and use by other networks(e.g., the first network, etc.). In block 316, the second DSC 144 b maygenerate a resource allocation report, and send the generated resourceallocation report to the DPC 146 (e.g., via a resource communicationmessage). The DSC 144 b may be configured to generate the resourceallocation report to include information identifying the resources (orportions or amounts of resources) that are available for allocationand/or that have been marked, designated, or allocated by the secondnetwork.

In block 320, the DPC 146 may receive various resource status andallocation reports from DSCs 144 in many different networks, includingthe first and second DSCs 144 a, 144 b in the first and second networks.These reports may include information identifying variouscharacteristics, criteria, requirements, and conditions of the networksand their components, such as the ratio of the detected user traffic tothe total available spectrum resources, the amount of resources that arerequired by a network, the amount of resources that are available forallocation in a network, the types and capabilities of the wirelessdevices 102 that will use the allocated resources, system requirementsthat must be met before the wireless devices 102 access the allocatedresources, network rules and policies with respect to access and use ofresources, and other similar information.

In block 322, the DPC 146 may store the received reports (e.g., resourcestatus reports, resource allocation reports, etc.) in memory (e.g., anon-volatile memory). In block 324, the DPC 146 may receive a requestfor resources from DSCs 144 in different networks, including the firstDSC 144 a in the first network. In block 326, the DPC 146 may use thereceived/stored information (e.g., information received in requests forresources, resource allocation reports, resource status reports, etc.)to identify and select the most suitable/best available network fromwhich the first network may lease or purchase additional resources. Inthe example illustrated in FIG. 3, the DPC 146 identifies and selectsthe second network as the most suitable network to provide resources tothe first network.

In block 328, the DPC 146 may send a resource inquiry communicationmessage to the second DSC 1144 b. In block 330, the second DSC 1144 bmay receive the resource inquiry communication message. In block 332,the second DSC 1144 b may determine the availability, amounts, and/orquantity of the excess resources that are marked, designated, orallocated by the second network. In block 334, the second DSC 1144 b maygenerate and send a “resource inquiry response” communication message tothe DPC 146. The second DSC 1144 b may generate resource inquiryresponse to include information suitable for use in identifying theavailability and quantity of the resources that are marked, designated,or allocated for access and use by other networks (e.g., the firstnetwork). In block 336, the DPC 146 may receive the “resources inquiryresponse” communication message from the second DSC 1144 b, and inresponse, perform the operations of determination block 400 illustratedin FIG. 4.

With reference to FIG. 4, in determination block 400, the DPC 146 maydetermine whether resources are available based on the data (e.g.,resources inquiry response message) received from the second DSC 144 bin the second network. For example, the DPC 146 may determine that theidentified resources are not available in response to determining thatall or a portion of the resources were purchased or won by other biddersbefore they were reserved.

In response to determining that the resources are not available (i.e.,determination block 400=“No”), in block 402, the DPC 146 may send a “noresources available” communication message to the first DSC 144 a in thefirst network. In block 404, the first DSC 144 a may receive the “noresources available” communication message. In block 406, the first DSC144 a may search (e.g., via the DPC 146) for other available resources,request resources from a different network, request different resources,terminate connections or communication sessions with users to free-upresources, or perform other similar operations to manage network trafficand congestion in the first network.

In response to determining that the resources are available (i.e.,determination block 400=“Yes”), in block 408, the DPC 146 may send a“resources available” communication message to the first DSC 144 a. Theresources available message may include information that may be used bythe first DSC 144 a to determine the quality and quantity of resourcesin the second network that may be used by wireless devices 102 in thefirst network.

In block 410, the first DSC 144 a may receive the resources availablecommunication message sent from the DPC 146. In block 412, the first DSC144 a may determine the amount/quantity of resources that the firstnetwork requires and/or will attempt to acquire, and send this and otherresource information to the DPC 146 in a “request resources”communication message.

In block 414, the DPC 146 may receive the “request resources” messagefrom the first DSC 144 a. In block 416, the DPC 146 may use informationincluded in received message to generate and send a “reserve resourcesrequest” communication message to the second DSC 144 b in the secondnetwork.

In block 418, the second DSC 144 b may receive the “reserve resourcerequest” message from the DPC 146. In block 420, the second DSC 144 bmay use the information included in the received “reserve resourcesrequest” message to reserve the requested quantity of allocatedresources for access and use by components in other networks. In block422, the second DSC 144 b may send a “resource reserved” communicationmessage to the DPC 146 to confirm that the requested quantity ofresources has been reserved and/or to identify the reserved resources.

In block 424, the DPC 146 may receive the “resource reserved”communication message from the second DSC 144 b. In block 426, the DPC146 may offer the reserved resources for auction and/or begin acceptingresource bids on the reserved resources.

FIG. 5 illustrates a bidding procedure of the DSA method 300 that may beperformed after the DPC 146 offers the reserved resources for auctionand/or begins accepting resource bids on the reserved resources (e.g.,after performing the operations of block 426 illustrated in FIG. 4).

With reference to FIG. 5, in block 500, the first DSC 144 a in the firstnetwork may negotiate access to the reserved resources of second networkby sending a resource bid (e.g., via a communication message) to the DPC146. In block 502, the DPC 146 may receive the resource bid from thefirst DSC 144 a.

In determination block 504, the DPC 146 may determine whether thereceived resource bid is to be accepted, which may be accomplished bydetermining whether the resource bid complies with the policies andrules of the DSA system and the requirements of the second network(e.g., is greater than a minimum amount, etc.). In response todetermining that the resource bid received from the first DSC 144 a isto be accepted (i.e., determination block 504=“Yes”), in block 506, theDPC 146 may send an “accept bid” communication message to the first DSC144 a. In block 508, the first DSC 144 a may receive the “accept bid”message and wait to receive resource access instructions. In block 510,the DPC 146 may send an “assign resources” communication message to thesecond DSC 144 b in the second network.

In block 512, the second DSC 144 b may receive the “assign resources”communication message from the DPC 146. In block 514, the second DSC 144b may use the information included in the received “assign resources”message to assign all or portions of its reserved resources for accessand use by components in the first network. In block 516, the second DSC144 b may generate a “resources access” communication message thatincludes information (e.g., access parameters, etc.) that may be used bya wireless device 102 (i.e., in the first network) to access theassigned resources, and the send the “resources access” message to theDPC 146. In block 518, the second DSC 144 b may perform variousoperations to prepare for establishing a communication session/link towireless device 102 in the first network, such as by configuring orpreparing to receive a voice or data call.

In block 522, the DPC 146 may receive the “resources access”communication message from the second DSC 144 b, and relay the resourcesaccess message to the first DSC 144 a. In block 524, the first DSC 144 amay receive the “resources access” message from the DPC 146. Thereceived “resource access” message may include access parameters thatmay be used by the wireless devices 102 to access the allocatedresources of the second network. In block 526, the first DSC 144 a maysend access parameters to wireless devices 102 that have communicationsessions with the first network and/or to the wireless devices 102 thatthe first network has designated/marked for migration to other networks.

In block 528, the wireless devices 102 may receive the access parametersof second network from the first DSC 144 a. In blocks 530 and 520, thewireless devices 102 and/or second DSC 142 b may perform variousoperations to establish a communication session/link between thewireless devices 102 and the second network. The second DSC 144 b maythen perform the operations of block 700 illustrated in FIG. 7 anddiscussed further below.

As mentioned above, in determination block 504, the DPC 146 maydetermine whether the resource bid received from the first DSC 144 a isto be accepted. In response to determining that the resource bidreceived from the first DSC 144 a is not to be accepted (i.e.,determination block 504=“No”), the DPC 146 may perform the operations ofblock 600 illustrated in FIG. 6.

With reference to FIG. 6, in block 600, the DPC 146 may send a “rejectedbid” communication message to the first DSC 144 a. In block 602, thefirst DSC 144 a may receive the “rejected bid” message from the DPC 146.In determination block 604, the first DSC 144 a may determine whetherthe first network will/should rebid for the resources. In response todetermining that the first network will/should rebid for the resources(i.e., determination block 604=“Yes”), in block 606, the first DSC 144 amay send a new resource bid (e.g., in a resource bid communicationmessage) to the DPC 146.

In block 608, the DPC 146 may receive the new resource bid (or rebid)from the first DSC 144 a. In determination block 610, the DPC 146 maydetermine whether to accept the new resource bid, such as by determiningwhether the new resource bid complies with the policies and rules of theDSA system and the requirements of the second network. In response todetermining that the new resource bid is to be accepted (i.e.,determination block 610=“Yes”), the DPC 146 may perform the operationsof block 506 illustrated in FIG. 5. In response to deter mining that thenew resource bid is to not be accepted (i.e., determination block610=“No”), the DPC 146 may perform the operations of block 600.

In response to determining that the first network should rebid for theresources (i.e., determination block 604=“No”), in block 612, the firstDSC 144 a may send a “cancel resource request” communication message tothe DPC 146. In block 614, the DPC 146 may receive the “cancel resourcerequest” message from the first DSC 144 a. In block 616, the DPC 146 maysend a “release of resources” communication message to the second DSC144 b.

In block 618, the second DSC 144 b may receive the “release ofresources” message from the DPC 146. In block 620, the second DSC 144 bmay release the reserved resources so that they may be used by othernetworks. The second DSC 144 b may then report the status of theallocated resources to DPC 146, which may be accomplished by performingthe operations of block 316, which is illustrated in FIG. 3 anddiscussed above.

FIG. 7 illustrates settlement procedure of the DSA method 300 that maybe performed after second network provides access to the secondary userwireless devices 102 in the first network (i.e., after performing theoperations of block 520 illustrated in FIG. 5).

In block 700, the second DSC 144 b may send invoices and paymentinstructions relating to the use of allocated resources by the firstnetwork to the DPC 146. In block 704, the DPC 146 may relay the receivedinvoice and payment instructions to the first DSC 144 a. In block 706,the first DSC 144 a may receive the invoices and payment instructions,and settle the charges with the second network in block 718.

Optionally or alternatively, in block 708, the second DSC 144 b may sendusage parameters and payment instructions to the DPC 146. In block 710,the DPC 146 may receive the usage parameters and payment instructionsfrom the second DSC 144 b. In block 712, the DPC 146 may create aninvoice for the access and use of the resources. In block 714, the DPC146 may send the invoice to the first DSC 144 a in the first network. Inblock 716, the first DSC 144 a may receive the invoice and paymentinstructions, and perform various operations to settle the charges withsecond network in block 718.

In the various embodiments, the DPC 146 and DSC 144 components may beconfigured to communicate via an interface, which may be implemented in,or provided via, a dynamic spectrum arbitrage application part (DSAAP)protocol/module/component that is defined over the Xe and/or Xdreference points. The DSAAP may allow, facilitate, support, or augmentcommunications between the DPC 146 and DSC 144 so as to improve theefficiency and speed of the DSA system and telecommunication network. Invarious embodiments, all or portions of the DSAAP module/component maybe included in a DPC 146 component, a DSC 144 component, in a componentthat is independent of the DPC 146 and DSC 144 components, or anycombination thereof. The DSAAP module/component may allow these andother DSA components to communicate information using the DSAAPprotocol.

For example, the DSAAP may allow the DPC 146 and DSC 144 components tocommunicate specific information and/or perform operations that togetherprovide various functions, including a DSC registration function,resource availability advertisement function, bidding and allocation ofresources functions, handing off lessee users to lessor networkfunction, backoff from lessor networks function, error handling function(e.g., reporting of general error situations for which function specificerror messages are not defined, etc.), DSC de-registration function,error indication function, DSC bidding success and failure indicationfunctions, and DSC resource allocation withdrawal function. In variousembodiments, these functions may be provided, implemented, oraccomplished by configuring the DPC 146 and/or DSC 144 components toperform one or a combination of the DSAAP methods discussed below withreference to FIGS. 8A-17B. Using the DSAAP protocol and performing theDSAAP methods may include communicating via one or more DSAAP messages.

In various embodiments, the DSAAP messages used to communicateinformation between the DSC 144 and DPC 146 may include a DSC REGISTERREQUEST message, DSC REGISTER ACCEPT message, DSC REGISTER REJECTmessage, DSC DE-REGISTER message, DSC RESOURCE REGISTER REQUEST message,DSC RESOURCE REGISTER ACCEPT message, DSC RESOURCE REGISTER REJECTmessage, AVAILABLE BIDS REQUEST message, AVAILABLE BIDS RESPONSEmessage, AVAILABLE BIDS REJECT message, DSC BID REQUEST message, DSC BIDACCEPT message, DSC BID REJECT message, DSC BID OUTBID message, DSC BIDWON message, DSC BID LOST message, DSC BID CANCELLED message, DSC BUYREQUEST message, DSC BUY ACCEPT message, DSC BUY REJECT message, DSCRESOURCES ALLOCATED message, DSC RESOURCES WITHDRAWN message, and/or DSCBACKOFF COMMAND message. Each of these messages may include, or may beassociated with, criticality information, presence information, rangeinformation, and assigned criticality information. These messages andtheir contents are discussed in detail further below.

In various embodiments, the DSAAP methods may be performed in a DSAsystem that includes a first DSC server in a first telecommunicationnetwork (e.g., a lessee network), a second DSC server in secondtelecommunication network (e.g., a lessor network), and a DPC serverthat is outside of the first and second telecommunication networks. Thefirst DSC may include first DSC processor coupled to the DPC via a firstcommunication link, and the second DSC may include a second DSCprocessor coupled to the DPC via a second communication link. The secondDSC may be coupled to an eNodeB in the second telecommunication networkvia third communication link. The first and second communication linksmay be defined over the Xd interface, and the third communication linkis defined over the Xe interface.

FIGS. 8A through 8C illustrate an embodiment DSAAP registration method800 for registering a DSC 144 component with a DPC 146 so as to allowthe DPC 146 to provide various services to the DSC 144 (e.g.,advertizing a lessor DSC's 144 resources for bidding, allowing a lesseeDSC 144 to bid for resources provided by other networks, etc.). In theexamples illustrated in FIGS. 8A through 8C, the DSAAP registrationmethod 800 is performed by processing cores in a DPC 146 component and aDSC 144 component, each of which may include all or portions of a DSAAPmodule/component. The operations DSAAP registration method 800 may beperformed after, or in response to the DSC 144 or DPC 146 detectingthat, an XE signaling transport or communication link has beenestablished.

In operation 802 illustrated in FIGS. 8A through 8C, the DSC 144 mayinitiate DSAAP registration method 800 by generating and sending a DSCREGISTER REQUEST message to the DPC 146. In an embodiment, the DSC 144may be configured to generate and/or send the DSC REGISTER REQUESTmessage in response to determining that it requires services from theDPC 146. For example, the DSC 144 may be configured to generate the DSCREGISTER REQUEST message in response to determining that itscorresponding network (i.e., the network represented by the DSC)includes excess resources that may be allocated to other networks. Asanother example, the DSC 144 may be configured to generate the DSCREGISTER REQUEST message in response to determining that its networkrequires additional resources to provide adequate service to itsexisting wireless devices 102 in view of the current or expected futureuser traffic, network congestion, etc.

In various embodiments, the DSC 144 may be configured to generate theDSC REGISTER REQUEST message to include any or all of a message typeinformation element (IE), a message ID IE, a DSC identity IE, a DSCInternet protocol (IP) address IE, a DSC type IE, a DSC PLMN-ID IE, PLMNtype IE, and DSC resource update timer IE. The DSC PLMN-ID IE mayinclude a PLMN-ID that is suitable for use in identifying the network(e.g., E-UTRAN) that is associated with, or represented by, the DSC 144.The PLMN type IE may include information that is suitable for use indetermining the type of network (e.g., public safety, commercial, etc.)that is represented by the DSC 144. The DSC IP address IE may includethe IP address of a DSC 144 that is responsible for managing,maintaining, or providing the XE interface of the DSAAP.

In operation block 804 illustrated in FIGS. 8A and 8B, the DPC 146 mayperform various registration operations (i.e., authenticating the DSC,storing DSC identifier information in memory, etc.) to register the DSC144 with the DPC 146. In an embodiment, as part of these registrationoperations, the DPC 146 may overwrite/override an existing registrationwith a new registration, such as in response to receiving a duplicateDSC REGISTER REQUEST message (i.e. for an already registered DSCidentified by the same unique DSC identity).

In operation block 806 illustrated in FIG. 8A, the DPC 146 may determinethat the registration operations were successful. In operation 808, theDPC 146 may generate and send a DSC REGISTER ACCEPT message to the DSC144 to indicate the acceptance and registration of the DSC 144. Invarious embodiments, the DPC 146 may generate the DSC REGISTER ACCEPTmessage to include any or all of a message type information element(IE), a message ID IE, a DPC ID IE, a XEh signaling transport networklayer (TNL) address IE, and a tunneling information IE. The XEhsignaling TNL address IE may include an address value that is suitablefor use in establishing to transport layer session. The tunnelinginformation IE may include information that may used to encapsulate adifferent payload protocol, establish a secured communication through anuntrusted or unverified network, carry a payload over an incompatibledelivery-network, and/or to perform other similar tunneling operations.

To support XEh connectivity via/to the DPC 146, in operation block 810,the DSC 144 may use the address value included in the XEh signaling TNLaddress IE of the DSC REGISTER ACCEPT message establish a transportlayer session. In an embodiment, the DSC 144 may be configured toestablish the transport layer session in response to determining thatthe DSC REGISTER ACCEPT message includes an address value in the XEhsignaling TNL address information element. In an embodiment, the DSC 144may be configured to determine that the XEh connectivity via/to the DPC146 is not supported or not required in response to determining that theXEh signaling TNL address information element is not present, null,empty, or not valid.

With reference to FIG. 8B, in operation block 812, the DPC 146 maydetermine that the registration operations performed as part ofoperation 804 failed. The DPC 146 may determine that registration failedin response to detecting any of a variety of conditions/events,including the failure to authenticate or authorize the DSC, network orcomponent overload, DSC parameter mismatch, etc. In operation 814, theDPC 146 may generate and send a DSC REGISTER REJECT message to the DSC144 to inform the DSC 144 that the registration failed and/or that theDPC 146 cannot register the DSC 144. In various embodiments, the DPC 146may generate the DSC REGISTER REJECT message to include any or all of amessage type information element (IE), a message ID IE, a cause IE, acriticality diagnostics IE, and a backoff timer IE. The cause IE mayinclude information suitable for identifying a specific reason for thefailure (e.g., overloaded, etc.) or for indicating that the reason forthe failure is not known or is unspecified.

In operation block 816, the DSC 144 may perform various registrationfailure-response operations based on the information included in thereceived REGISTER REJECT message. For example, the DSC 144 may wait fora duration indicated in the backoff timer IE of the received REGISTERREJECT message before reattempting registration with that same DPC 146in response to determining that the value of the cause IE in thereceived REGISTER REJECT message is set to “overload.”

With reference to FIG. 8C, in operation block 852, the DSC 144 may starta register response timer in response to sending a DSC REGISTER REQUESTmessage to the DPC 146 (e.g., as part of operation 802). In operationblock 854, the DSC 144 may determine that the register response timerexpired before the DSC 144 received a DSC REGISTER RESPONSE message. Inoperation 856, the DSC 144 may resend the DSC REGISTER REQUEST messageto the DPC 146 in response to determining that the timer expired beforeit received a corresponding DSC REGISTER RESPONSE message. In operationblock 858, the DSC 144 may restart or reset the register response timer.In operation 860, the DPC may send a DSC REGISTER RESPONSE message tothe DSC 144. In operation block 862, the DSC 144 may stop the registerresponse timer in response to receiving the DSC REGISTER RESPONSEmessage.

FIGS. 9A and 9B illustrate a DSAAP advertizing method 900 foradvertizing resources that are available for bidding/buying so as toallow the DPC 146 to store, organize, and/or make those resourcesavailable for bidding/allocation via a financial brokerage platform. Inthe examples illustrated in FIGS. 9A and 9B, the DSAAP advertizingmethod 900 is performed by processing cores in a DPC 146 component and aDSC 144 component, each of which may include all or portions of a DSAAPmodule/component.

In operation block 902 illustrated in FIGS. 9A and 9B, the DSC 144 maydetermine that there are resources available for allocation within cellsserviced by that DSC 144. In operation block 904, the DSC 144 maygenerate and send a DSC RESOURCE REGISTER REQUEST message to the DPC146. In various embodiments, the DSC 144 may generate the DSC RESOURCEREGISTER REQUEST message to include any or all of a message typeinformation element (IE), a message ID IE, a DSC identity IE, a DSC typeIE, a PLMN-ID list IE, resource availability IE, resource availabilitystart time IE, a data bandwidth IE, a list of grids IE, a bid or buy IE,a minimum bid amount IE, resource availability end time IE, a time ofthe day IE, a time duration IE, megabits per second (MBPS) IE, and acell identity IE.

The DSC identity IE may include information that may be used by the DPC146 to determine the identity of DSC 144. For example, the DSC identityIE may include a DSC pool ID, DSC instance information, and a PLMN-ID ofthe network that the DSC is managing or representing. The DSC pool IDmay be a unique identifier of a pool of available resources and/or maybe the same as or similar to MME pool IDs and MME IDs in 3GPP EPCarchitecture.

The message ID IE may include a message identifier for the specific DSCRESOURCE REGISTER REQUEST message sent from the DSC 144. The DSC 144 andDPC 146 may be configured to use the message ID IE as a sequence numberto identify and correlate DSC RESOURCE REGISTER REQUEST, DSC RESOURCEREGISTER ACCEPT and/or DSC RESOURCE REGISTER REJECT messages.

The resource availability IE may include information suitable for use bythe DPC 146 in determining the PLMN-ID of the network that isadvertising resources for allocation and use by other networks. The DPC146 may be configured to receive, store, and/or maintain resourceavailability IEs for multiple DSCs and/or for multiple differentnetworks (i.e. different PLMN-IDs). As such, each resource availabilityIE may include information suitable for identifying one or more of thenetworks that are advertising resources.

The time of the day IE may include information suitable for use by theDPC 146 in determining the time of the day that the DSC 144 transmittedthe DSC RESOURCE REGISTER REQUEST message. The time duration IE mayinclude information that is suitable for use in determining a timeperiod during which the resources are to be made available for biddingor buying.

The data bandwidth IE may include information suitable for use indetermining the available bandwidth (e.g., in MBPS) for the timeduration specified in the optional time duration IE. The DPC 146 maydetermine that the bandwidth specified in the MBPS IE is to be madeavailable until that bandwidth is consumed by the winning bidder orbuyer in response to determining that the time duration IE is notincluded in the received DSC RESOURCE REGISTER REQUEST message (or inresponse to determining that the time duration IE does not include avalid value).

The list of grids IE may include information suitable for use indetermining grid identifiers for the locations of the network bandwidththat is to be made available for bidding or buying. The cell identity IEmay include information suitable for use in determining the individualcells within each grid (identified by grid ID and cell ID) that haveavailable resources offered for bidding or buying as part of the offerin the DSC RESOURCE REGISTER REQUEST message. The minimum bid amount IEmay include a monetary amount in a denomination or currency, such as inUnited States Dollars (USD).

In operation block 906 illustrated in FIG. 9A, the DPC 146 may acceptthe DSC's 144 resources for bidding. In operation 908, the DPC 146 maygenerate and send a DSC RESOURCE REGISTER RESPONSE or DSC RESOURCEREGISTER ACCEPT message to the DSC 144 to acknowledge that the resourceswere accepted. In various embodiments, the DPC 146 may generate the DSCRESOURCE REGISTER message to include any or all of a message typeinformation element (IE), a bid ID IE, and a message ID IE. The messageID IE may include the same message identifier value that is included inthe received DSC RESOURCE REGISTER REQUEST message. The DPC 146 and/orDSC may be configured to use the value of the message ID IE to identifyand correlate the DSC RESOURCE REGISTER REQUEST and DSC RESOURCEREGISTER ACCEPT messages. In operation block 910, the DPC 146 may store,organize, and/or make the network resources available for bidding orbuying via the financial brokerage platform.

In operation 912 illustrated in FIG. 9B, the DPC 146 may reject the DSCRESOURCE REGISTER REQUEST message and/or reject for bidding theresources identified in the received DSC RESOURCE REGISTER REQUESTmessage. The DPC 146 may reject the message/resources for a variety ofreasons and/or in response to detecting any of a variety of events orconditions. For example, the DPC 146 may reject the resources inresponse to determining that the DPC 146 is not accepting resources fromany operator, is not accepting resources for the specific operatoridentified in the received message, is not accepting the resourcesidentified in the message, that the DPC is overloaded, that there isinsufficient memory to store and service the resources available forbidding, etc. The DPC 146 may also reject the resource available messagein response to determining that an administrator of the DPC 146 hasdisabled further bidding from the specific PLMN-ID included in the DSCRESOURCE REGISTER REQUEST message, from all the networks (e.g., all thePLMN-IDs), etc.

In operation 914 illustrated in FIG. 9B, the DPC 146 may generate andsend a DSC RESOURCE REGISTER REJECT message to the DSC 144. In variousembodiments, the DPC 146 may generate the DSC RESOURCE REGISTER REJECTmessage to include any or all of a message type information element(IE), a message ID IE, a cause IE, and a criticality diagnostics IE. TheDPC 146 may also generate the DSC RESOURCE REGISTER REJECT message toinclude a message ID IE that includes a value that is the same as themessage identifier included in the DSC RESOURCE REGISTER REQUEST messagereceived from DSC 144. The DPC 146 and/or DSC 144 may be configured touse the value of the message ID IE to identify and correlate the DSCRESOURCE REGISTER REQUEST and DSC RESOURCE REGISTER REJECT messages.

In operation block 916, the DSC 144 may perform various resourceregistration failure response operations based on information includedin the received DSC RESOURCE REGISTER REJECT message. For example, theDSC 144 may use the information included in the DSC RESOURCE REGISTERREJECT message to determine whether to reattempt resource registrationwith the DPC 146, attempt to register the resources with another DPC,reattempt the registration with different resources, or perform any ofthe other DSC operations discussed in this application.

FIGS. 10A and 10B illustrate a DSAAP method 1000 for communicating alist of available resources in accordance with an embodiment. DSAAPmethod 1000 may be performed to inform lessee networks of the resourcebids or resources that are available for bidding/buying. In the examplesillustrated in FIGS. 10A and 10B, the DSAAP method 1000 is performed byprocessing cores in a DPC 146 component and a DSC 144 component, each ofwhich may include all or portions of a DSAAP module/component. In anembodiment, a lessee DSC 144 may be configured to perform DSAAP method1000 to retrieve/receive a list of available resources prior to that DSC144 bidding on, or requesting to lease or purchase, resources from theDPC 146.

In operation 1002 illustrated in FIGS. 10A and 10B, a lessee DSC 144 maygenerate and send an AVAILABLE BIDS REQUEST message to the DPC 146 torequest information on the resource bids that are available forallocation from lessor network(s) for bidding or buying. In variousembodiments, the lessee DSC 144 may generate the AVAILABLE BIDS REQUESTmessage to include any or all of a sequence number information element(IE), a message type IE, a PLMN list IE that includes one or morePLMN-ID IEs, a grid ID list IE that includes one or more Grid ID IEs.

In an embodiment, the lessee DSC 144 may be configured to requestspecific resources from a specific network by generating the AVAILABLEBIDS REQUEST message to include the PLMN-ID of the desired network,which may be included in the PLMN-ID IE of the PLMN list IE in theAVAILABLE BIDS REQUEST message.

In an embodiment, the lessee DSC 144 may be configured to requestresources from any available network by not populating the PLMN list IEin the generated AVAILABLE BIDS REQUEST message and/or by generating theAVAILABLE BIDS REQUEST message to not include a PLMN list IE and/orPLMN-ID value.

In an embodiment, the lessee DSC 144 may be configured to requestresources from a specific grid within a lessor network by generating theAVAILABLE BIDS REQUEST message to include the grid IDs of the desiredgrids, which may be included in the grid ID IE of the grid ID list IE inthe AVAILABLE BIDS REQUEST message.

In an embodiment, the lessee DSC 144 may be configured to requestresources from any or all grids within a specified PLMN-ID in PLMN-ID IEgrid by not populating the grid ID list IE in the generated AVAILABLEBIDS REQUEST message and/or by generating the AVAILABLE BIDS REQUESTmessage to not include a grid ID.

In operation block 1004 illustrated in FIGS. 10A and 10B, the DPC 146may determine whether the PLMN-ID(s) and grid ID(s) included in thereceived AVAILABLE BIDS REQUEST message are valid. If the PLMN-ID(s) andgrid ID(s) are incorrect, in operation block 1005, the DPC 146 maydetermine a reason code for the error/incorrect values. In operationblock 1006, the DPC 146 may determine whether there are resources/bidsavailable for each grid identified in the received AVAILABLE BIDSREQUEST message or for all the available grids (e.g., when the grid IDlist IE in the received AVAILABLE BIDS REQUEST message not include validvalues).

In operation 1008 illustrated in FIG. 10A, the DPC 146 may generate andsend an AVAILABLE BIDS RESPONSE message to the DSC 144. The DPC 146 maybe configured to generate the AVAILABLE BIDS RESPONSE message to includeany or all of a message type information element (IE), a message ID IE,a DSC identity IE, a PLMN-ID grid cell bid info list IE, a sequencenumber IE, a PLMN list IE that includes one or more PLMN-ID IEs, and agrid list IE. In an embodiment, the PLMN list IE and grid list IE may beincluded in the PLMN-ID grid cell bid info list IE. In an embodiment,the grid list IE may include one or more cell ID list IEs that includeone or more cell ID IEs.

In various embodiments, the DPC 146 may generate the AVAILABLE BIDSRESPONSE message to also include any or all of an absoluteradio-frequency channel number (ARFCN) IE, a channel bandwidth IE, amegabit or megabyte IE for identifying total available bandwidth, a MBPSIE for identifying the peak data rate for the resource, a resourceavailable time IE, a resource expiration time IE, a bid/buy IE, abid/buy expiry time IE, a minimum bid amount IE, and a buy price IE. TheDPC 146 may generate the AVAILABLE BIDS RESPONSE message to include suchinformation for each PMLN, each resource, each grid, and/or each cellidentified in the message.

In an embodiment, the DPC 146 may be configured to generate theAVAILABLE BIDS RESPONSE message to include the list of PLMN-ID, lists ofgrid ID(s) within each PLMN, and the available resources/bids withineach grid in response to determining that there are bids for resourcesavailable for auction.

In an embodiment, the DPC 146 may be configured to generate theAVAILABLE BIDS RESPONSE message to include the message type and sequencenumber IEs (or valid values for these IEs) in response to determiningthat there no resources/bids for resources available for auction by thatDPC 146 for the relevant networks/PLMN-IDs. In an embodiment, the DPC146 may be configured to generate the AVAILABLE BIDS RESPONSE message toinclude a sequence number IE having the same value as in the sequencenumber IE included in the received AVAILABLE BIDS REQUEST message. In anembodiment, the DSC 144 may be configured to use the sequence number IEsin these request and response messages to correlate the messages.

In an embodiment, the DPC 146 may be configured to generate theAVAILABLE BIDS RESPONSE message to include a PLMN list IE that includesa PLMN-ID and grid ID list IE. The grid ID list IE may include a list ofcells available for auction within the grid. The cell ID list IE mayinclude a cell ID, and for each cell, the ARFCN, channel bandwidth,total available bandwidth, peak data rate allowed, the time of day(e.g., in UTC) when the resources are available and when theyexpire/end, whether it's a bid or buy type auction, minimum bid amountor buy price, bid expiry time (e.g., in UTC), and other similarinformation.

In operation block 1010, the DSC 144 may use the information included inthe AVAILABLE BIDS RESPONSE message to identify the resources that areavailable for bidding, determine whether the DSC 144 will submit a bidfor the available resources, determine the resources for which the DSC144 will submit bids, and/or perform other similar operations.

With reference to FIG. 10B, in operation 1012, the DPC 146 may rejectthe AVAILABLE BIDS REQUEST message received from lessee DSC 144 bygenerating and sending a AVAILABLE BIDS REJECT message to the DSC 144.The DPC 146 may be configured to reject the AVAILABLE BIDS REQUESTmessage in response to determining (e.g., as part of operation 1004 or1006) that one or more of the PLMN-IDs supplied in the request messageis not from any of the known networks, that one or more of the Grid IDssupplied in the request message is not valid with respect to thesupplied PLMN-ID, and/or that there are no resources/bids available inthe relevant grids.

In an embodiment, the DPC 146 may be configured to generate theAVAILABLE BIDS REJECT message to include a message type informationelement (IE), a message ID IE, a cause IE, a criticality diagnostics IE,and a sequence number IE. The cause IE may include a reason code (e.g.,Invalid PLMN-ID, Invalid Grid ID, etc.) for the rejection of theavailable bids request, which may be determined in operation block 1005.The sequence number IE may include the same sequence number value thatwas included in the AVAILABLE BIDS REQUEST message received from lesseeDSC 144. As such, the DPC 146 and/or DSC 144 may be configured to usesequence number IEs in the request and response messages to correlatethose messages.

In operation block 1014, the DSC 144 may use the information included inthe received AVAILABLE BIDS REJECT message to perform variousfailure-response operations. For example, the DSC 144 may determinewhether to send another AVAILABLE BIDS REQUEST message to the DPC 146,determine whether to send another AVAILABLE BIDS REQUEST message to adifferent DPC, etc.

FIGS. 11A and 11B illustrate a DSAAP bidding method 1100 of bidding forDSC resources, which allows different lessee networks to bid forresources that are available from lessor networks. In the examplesillustrated in FIGS. 11A and 11B, the DSAAP method 1100 is performed byprocessing cores in a DPC 146 component and a DSC 144 component, each ofwhich may include all or portions of a DSAAP module/component.

In an embodiment, the DSC 144 and/or DPC 146 may be configured toperform DSAAP method 1100 after the DSC 144 retrieves the list ofresources that are available for bidding (e.g., after performing DSAAPmethod 1000). In various embodiments, the DSC 144 and/or DPC 146 may beconfigured to perform DSAAP method 1100 continuously or repeatedly untilthe expiration of a bidding time. In an embodiment, the DPC 146 may beconfigured to select a winning bid (i.e., bid highest bid value) at theexpiry of a bidding time.

In operation 1102 of method 1100 illustrated in FIGS. 11A and 11B, thelessee DSC 144 may generate and send a DSC BID REQUEST message to theDPC 146 to bid for one or more of the resource that are determined to beavailable from a lessor network, (i.e., one or more of resourcesincluded the list of resources obtained via the performance of method1000). The lessee DSC 144 may be configured to generate the DSC BIDREQUEST message to include any or all of a message type informationelement (IE), a message ID IE, a DSC identity IE, a DSC type IE, bid IDIE, a PLMN-ID IE, and a bid amount IE. The bid ID IE may includeinformation suitable for identifying a specific resource for which thelessee DSC 144 places a bid. The PLMN-ID IE may include informationsuitable for use in identifying the PLMN-ID of the network associatedwith the resources identified in the bid ID IE. The bid amount IE mayinclude a monetary amount in a currency (e.g., USD), or the bid value.

In an embodiment, the lessee DSC 144 may be configured to generate theDSC BID REQUEST message to include a bid amount IE value that is greaterthan a minimum bid amount specified in a bid listing for the specificresource/bid ID. In an embodiment, the lessee DSC 144 may be configuredto obtain the minimum bid amount and/or bid listing from the receivedAVAILABLE BIDS RESPONSE message (e.g., the message sent as part ofoperation 1008 illustrated in FIG. 10A).

In operation block 1104 illustrated in FIG. 11A, the DPC 146 may use theinformation included in the received DSC BID REQUEST message todetermine whether the bid (resource bid) is valid and is to be accepted,such as by determining whether the bid complies with the policies andrules of the DSA system and the requirements of the lessor network. Inoperation 1106, the DPC 146 may generate and send DSC BID ACCEPT messageto the DSC in response to determining that the bid is valid and/or is tobe accepted. The DPC 146 may be configured to generate the DSC BIDACCEPT message to include any or all of a message type informationelement (IE), a message ID IE, a bid ID IE, and other informationsuitable for informing the DSC 144 that the bid has been determined tobe valid and/or has been accepted.

It should be noted that, in the example discussed above, the DSC BIDACCEPT message informs the DSC 144 that the bid is valid/accepted, notthat lessee DSC 144 has won the bid. The winning lessee DSC may beinformed via DSC BID WON message when the DPC 146 determines that thebid time has expired and that lessee DSC is the highest bidder at thetime of bid expiry. Similarly, the DPC 146 may inform lessee DSC(s) whoparticipated in the bidding process but submitted losing bids that theydid not submit a winning bid via a DSC BID LOST message. The DSC BID WONmessage and DSC BID LOST message are discussed in more detail furtherbelow.

With reference to FIG. 11B, in operation block 1108, the DPC 146 may usethe information included in the received DSC BID REQUEST message todetermine that the bid is not valid and is not to be accepted. Forexample, the DPC 146 may use the received information to determine thatthe bid does not comply with the policies/rules of the DSA system and/ordoes not comply with the requirements of the lessor network (e.g., doesnot meet the minimum asking price, etc.). As further examples, the DPC146 may be configured to determine that the bid is not valid or is notto be accepted in response to determining that the bid amount specificin bid amount IE in the BID REQUEST message is not higher than theminimum bid, that the bid amount is not the highest among currentlyoffered bids, that the bid id included in the bid ID IE is invalid, orthat the bid/resource is no longer available for bidding (e.g., due toexpiry, end of auction, bid withdrawn or invalid bid id).

In operation 1110, the DPC 146 may generate and send a DSC BID REJECTmessage to the DSC 144. The DPC 146 may be configured to generate theDSC BID REJECT message to include any or all of a message typeinformation element (IE), a message ID IE, a bid ID IE, a cause IE, anda criticality diagnostics IE. The bid ID IE in the DSC BID REJECTmessage may include the same value as the bid identifier included in thereceived DSC BID REQUEST message. The cause IE may include a reason codeidentifying a reason for the rejection of the bid (e.g., minimum bid notmet, outbid, bid not found, etc.). In operation block 1112, the DSC 144may use information included in the received DSC BID REJECT message toperform various bid request failure-response operations, such asoperations to determine whether to rebid for the resources, to generatea new DSC BID REQUEST message that includes a valid bid ID, etc.

FIGS. 12A through 12D illustrate a DSAAP notification method 1200 ofinforming participating networks of the results of the biddingoperations. That is, DSAAP notification method 1200 may be performed toinform DSCs 144 of a result of an auction (e.g., that they submitted awinning bid, that they have been outbid, that they submitted a losingbid, that the auction was cancelled, etc.). In the examples illustratedin FIGS. 12A-12D, the DSAAP notification method 1200 is performed byprocessing cores in a DPC 146 component and a DSC 144 component, each ofwhich may include all or portions of a DSAAP module/component.

DSAAP notification method 1200 may be performed after the DPC 146notifies the DSC 144 that the bid has been accepted (e.g., afteroperation 1106 illustrated in FIG. 11). The DSAAP notification method1200 also may be performed after the expiry of a bidding time and/or inresponse to the DPC 146 detecting an event or condition (e.g., new bidreceived, outbid, etc.).

In operation block 1202 illustrated in FIG. 12A, the DPC 146 maydetermine that the bid amount specific in bid amount IE in the last,latest, or most current BID REQUEST message accepted from the DSC 144 isnot the highest among the current bids. In operation 1204, the DPC 146may generate and send a DSC BID OUTBID message to the DSC 144 to informthe lessee DSC 144 that its earlier bid was outbid by a higher bid fromanother lessee DSC and/or that their earlier bid is no longer valid. Invarious embodiments, the DPC 146 may generate the DSC BID OUTBID messageto include any or all of a message type information element (IE), amessage ID IE, a cause IE, a bid info IE, a criticality diagnostics IE,a DSC ID IE and a BID ID IE.

The DSC ID IE may include information that is suitable for use inidentifying the specific lessee DSC 144. The BID ID IE may include a bidID suitable for use in identifying the submitted bid that has beenoutbid. In operation block 1206, the lessee DSC 144 may perform variousbid-outbid failure-response operations, such as by determining whetherto submit a higher bid for the resources to that DPC 146, to submit abid to a different DPC 146, to drop existing calls to free bandwidth,etc.

With reference to FIG. 12B, in operation block 1210, the DPC 146 maydetermine that the bidding time has expired and that the bid amountspecific in bid amount IE in the last, latest, or most current BIDREQUEST message accepted from the DSC 144 is the highest among thecurrent bids. In operation 1212, the DPC 146 may generate and send a DSCBID WON message to the DSC 144 to inform the lessee DSC 144 that theirearlier bid is the winning bid. In various embodiments, the DPC 146 maygenerate the DSC BID WON message to include any or all of a message typeinformation element (IE), a message ID IE, a bid ID IE, a bid info IE, aDSC ID IE, and original bid details such as bandwidth, MBPS, durationand the winning bid amount, etc. The DSC ID IE may include informationthat is suitable for use in identifying the specific lessee DSC 144. Thebid ID IE may include a bid identifier suitable for identifying the bidthat won the resource auction/bidding operations.

In operation block 1214, the winning lessee DSC 144 may wait to receiveDSC RESOURCES ALLOCATED message from the DPC 146 before scheduling itsnetwork equipment and device (e.g., wireless devices) to start using theresources and/or for the resources to be made available for use (i.e.scheduling for the time of day when the resources will be ready for useby the winning lessee network). In operation block 1216, the DPC 146 mayclose the auction, such as by rejecting further bids from other networksfor the resources won by the bid submitted by lessee DSC 144.

With reference to FIG. 12C, in operation block 1220, the DPC 146 maydetermine that the bidding time has expired and that the bid amountspecific in bid amount IE in the last, latest, or most current BIDREQUEST message accepted from the DSC 144 is not the highest among thecurrent bids. In operation 1222, the DPC 146 may generate and send a DSCBID LOST message to the DSC 144 to inform the lessee DSC 144 that itsearlier bid has not won the bid and the auction/bid is closed due toanother lessee DSC winning the auction. In various embodiments, the DPC146 may generate the DSC BID LOST message to include any or all of amessage type information element (IE), a message ID IE, a bid ID IE, anda DSC ID IE. The DSC ID IE may include information that is suitable foruse in identifying the specific lessee DSC 144 that submitted the losingbid and/or to which the DSC BID LOST message is sent. The bid ID IE mayinclude a bid identifier suitable for use in identifying the submittedbid.

In operation block 1224, the lessee DSC 144 may perform various failureresponse operations, such as determining whether to submit a bid to forother available resources, whether to drop existing calls to free upresources, etc. In operation block 1226, the DPC 146 may close theauction and/or allow the losing lessee DSCs to bid for other availableresources.

With reference to FIG. 12D, in operation block 1230, the DPC 146 maydetermine that the auction for a network resource that the DSC 144previously submitted a bid has been cancelled. For example, the DPC 146may determine that the auction has been withdrawn by lessor networkoperator or that the auction has been cancelled by DPC operator foradministrative reasons. In operation 1232, the DPC 146 may generate andsend a DSC BID CANCELLED message to the DSC 144 to inform the lessee DSC144 that the auction has been cancelled. In various embodiments, the DPC146 may generate the DSC BID CANCELLED message to include any or all ofa message type information element (IE), a message ID IE, a bid ID IE, aDSC ID IE, and a cause IE. The DSC ID IE may include information that issuitable for use in identifying the specific lessee DSC 144. The bid IDIE may include a bid identifier suitable for use in identifying theresource/bid for which the auction has been cancelled. The cause IE mayinclude a reason code for the bid's cancellation (e.g., auctionwithdrawn, auction cancelled, etc.). In operation block 1234, the lesseeDSC 144 may perform various failure-response operations, such as bydetermining whether to submit a bid to a different DPC 146, to dropcalls, etc.

FIGS. 13A and 13B illustrate a DSAAP purchase method 1300 of allowing alessee network to make an immediate (or near immediate) purchase and/orclaim of use for a resource that is made available for allocation by alessor network. In the examples illustrated in FIGS. 13A and 13B, theDSAAP purchasing method 1300 is performed by processing cores in a DPC146 component and a DSC 144 component, each of which may include all orportions of a DSAAP module/component. In an embodiment, the DSC 144 andDPC 146 may be configured to perform DSAAP method 1300 after the DSC 144retrieves/receives a list of resources that are available for purchase(e.g., after perform DSAAP method 1000 discussed above with reference toFIG. 10).

In operation block 1302 illustrated in FIGS. 13A and 13B, the lessee DSC144 may identify and select a specific resource for immediate purchasefrom the list of resources (e.g., list of resources obtained fromperforming DSAAP method 1000 discussed above). In various theembodiments, the lessee DSC 144 may select a resource that is scheduledfor bidding, that is currently being auctioned, that is only madeavailable for immediate purchase, etc. In operation 1304, the DSC 144may generate and send DSC BUY REQUEST message to the DPC 146 to requestto buy the identified/selected resources from a lessor network.

In various embodiments, the DSC 144 may generate the DSC BUY REQUESTmessage to include any or all of a message type information element(IE), a message ID IE, a DSC identity IE, a DSC type IE, a bid ID IE, abuy amount IE, and a PLMN-ID IE. The PLMN-ID IE may include informationsuitable for use in identifying the PLMN-ID of the network associatedwith the bid, which may identified via the bid ID IE. The buy amount IEmay include the amount (e.g., in USD) of the bid (i.e., bid value)submitted by the lessee DSC 144.

In an embodiment, the DSC 144 may be configured to generate the DSC BUYREQUEST message to include a buy amount value that is equal to an amountidentified via a buy amount IE in a listing for the bid ID included in areceived AVAILABLE BIDS RESPONSE message (which is discussed above withreference to FIG. 10).

In operation block 1306 illustrated in FIG. 13A, the DPC 146 may use theinformation included in the received DSC BUY REQUEST message to identifythe requested resource, the network associated with the requestresource, whether the requested resource is currently being auctioned,whether the requested resource has been made available for immediatepurchase, a minimum purchase amount requested for the immediate purchaseof that resource, and/or whether the buy amount included in the receivedDSC BUY REQUEST message is equal to (or greater than) the requestedpurchase amount. In the example illustrated in FIG. 13A, as part ofoperation block 1306, the DPC 146 determines that the buy amountincluded in the received DSC BUY REQUEST message is greater than orequal to the requested purchase amount.

In operation 1308, the DPC 146 may generate and send a DSC BUY ACCEPTmessage to the DSC 144 to inform the lessee DSC 144 that it hassuccessfully purchased/leased the resource for use. In variousembodiments, the DPC 146 may generate the DSC BUY ACCEPT message toinclude any or all of a message type information element (IE), a messageID IE, and a bid ID IE. In operation block 1310, the DPC 146 mayterminate, stop, or close an active auction for that resource and/orperform similar operations so that the resource is no longer availablefor bidding or buying by other lessee DSCs.

With reference to FIG. 13B, in operation block 1312, the DPC 146 may usethe information included in the received DSC BUY REQUEST message (e.g.,as part of operation 1304) to determine that the bid (buy request) is tobe rejected. For example, the DPC 146 may determine that the buy amountspecific in buy amount IE in the received DSC BUY REQUEST message isless than the requested purchase amount. As another example, the DPC 146may determine that the bid ID value included in the bid ID IE isinvalid, or that the resource/bid is no longer available for bidding(due to expiry, end of auction, bid withdrawn, invalid bid ID, etc.).

In operation 1314, the DPC 146 may generate and send a DSC BUY REJECTmessage to the DSC 144. In various embodiments, the DPC 146 may generatethe DSC BUY REJECT message to include any or all of a message typeinformation element (IE), a message ID IE, a bid ID IE and a cause IE.The value of the bid ID IE may be the same as the bid identifierincluded in the DSC BUY REQUEST message received as part of operation1304. The cause IE may include a reason code for the rejection of thebuy request (e.g., requested purchase price not met, bid not found,etc.). In operation block 1316, the DSC 1316 may perform variousfailure-response operations, such as determining whether to submit a newpurchase request with a higher bid amount. In operation block 1318, theDPC 146 perform various operations so to make that resource availablefor bidding or buying by other lessee DSCs.

FIGS. 14A and 14B illustrate a DSAAP resource allocation method 1400 ofallocating resources in a lessor network for access and use bycomponents in a lessee network. In the examples illustrated in FIGS. 14Aand 14B, the DSAAP resource allocation method 1400 is performed byprocessing cores in a DPC 146 component, a lessee DSC 144 a component,and a lessor DSC 144 b component, each of which may include all orportions of a DSAAP module/component.

In operation block 1402 illustrated in FIGS. 14A and 14B, the DPC 146may determine that the lessee DSC 144 a has successfully purchased orwon an auction for a resource in a lessor network represented by thelessor DSC 144 b. In operation 1404 illustrated in FIG. 14A, the DPC 146may generate and send a DSC BID SUCCESS message to the lessor DSC 144 bto inform the lessor network that one or more of its allocatedresources/bids has been won by the lessee DSC 144 a.

In various embodiments, the DPC 146 may generate the DSC BID SUCCESSmessage to include any or all of a message type information element(IE), a message ID IE, a cause IE, and a criticality diagnostics IE. Ina further embodiment, the DPC 146 may be configured to generate the DSCBID SUCCESS message to also include any or all of a bid ID IE, a DSC IDIE, and a bid value IE. These additional information elements may beused to communicate information regarding the winning bid. For example,the bid ID IE may include a bid ID that corresponds to the bid thatsuccessfully participated in and won the auction for the resources. TheDSC ID IE may include the DSC ID of the auction winner (i.e., the lesseeDSC 144 a). The bid value IE may include the winning bid amount and/orthe purchase price of the resources.

In operation 1404, the lessor DSC 144 b may generate and send DSCRESOURCES ALLOCATED message to the DPC 146 to allocate/commit theresources for access and use by components in the lessee network. Thelessor DSC 144 b may be configured to generate DSC RESOURCES ALLOCATEDmessage to include any or all of a message type information element(IE), a message ID IE, a bid iD, a PLMN-ID Grid ID Cell ID list IE, aPLMN-ID IE, a grid ID IE, list of cell IDs IE, and variousauction/resource details (e.g., bandwidth, MBPS, duration, etc.). In anembodiment, the PLMN-ID IE, a grid ID IE, and list of cell IDs IE may beincluded in the PLMN-ID Grid ID Cell ID list IE. The PLMN-ID IE mayinclude the PLMN-ID of the lessor network allocating the resources,which may be the same PLMN-ID/network identified in the winning bid. Thegrid ID IE and list of cell IDs IE may include information suitable foridentifying the grid/cells associated with the resources. These valuesmay be the same as the grid/cell values included in the winning bid.

In operation 1406, the DPC 146 may forward the received DSC RESOURCESALLOCATED message to the winning lessee DSC 144 a to enable the lesseeDSC 144 a to start using the allocated resources of lessor networkresources. In operation block 1408, the lessee DSC 144 a may scheduleits network equipment to start using lessor network resources from thetime of day specified as part of the bid and/or included in the receivedDSC RESOURCES ALLOCATED message.

With reference to FIG. 14B, in operation block 1410, the lessor DSC 144b may determine that the resources submitted for auction should bewithdrawn and/or to forego allocating the submitted resources to awinner of the auction. The lessor DSC 144 b may determine to withdrawthe resources after the DPC 146 determines that lessee network purchasedor won an auction for those resources and/or for any of a variety ofreasons (e.g., unforeseen or administrative reasons, etc.).

In operation 1412, the lessor DSC 144 b may generate and send a DSCRESOURCES WITHDRAWN message to the DPC 146 to withdraw the resources.The lessor DSC 144 b may generate the DSC RESOURCES WITHDRAWN message toinclude any or all of a message type information element (IE), a messageID IE, a bid ID IE, a cause IE, and a PLMN-ID Grid ID Cell ID list IE.The bid ID IE may include information that is suitable for use inidentifying the bid. The cause IE may include a reason code thatdescribes the reason for withdrawal of resource allocations (e.g.,resources not available, resources withdrawn, administrative, etc.).

In operation 1414, the DPC 146 may forward the received DSC RESOURCESWITHDRAWN message to the lessee DSC 144 a, which may have submitted awinning bid for the withdrawn resources. In operation block 1416, thelessee DSC 144 a may perform various failure-response operations, suchas determining whether to participate in another auction, whether to bidon a different resource, determining whether to drop calls to free upresources, etc.

FIGS. 15A and 15B illustrate an embodiment DSAAP backoff method 1500 ofselectively handing over a wireless device from a lessor network back tothe lessee's network to which the wireless device subscribes (i.e. itshome PLMN). In the examples illustrated in FIGS. 15A and 15B, the DSAAPbackoff method 1500 is performed by processing cores in a DPC 146component, a lessee DSC 144 a component, and a lessor DSC 144 bcomponent, each of which may include all or portions of a DSAAPmodule/component.

In operation block 1502 illustrated in FIGS. 15A and 15B, the lessor DSC144 b may determine that its network resources from the cells that arepart of a prior auction are in congestion. That is, the lessor DSC 144 bmay determine that it requires access or use of its allocated resources.In operation 1504, the lessor DSC 144 b may generate and send a DSCBACKOFF COMMAND message to the DPC 146 to selectively handover wirelessdevice(s) that are using the allocated resources of the lessor networkback to the lessee network (i.e. its home PLMN).

The lessor DSC 144 b may be configured to generate the DSC BACKOFFCOMMAND message to include any or all of a message type informationelement (IE), a message ID IE, a bid ID IE, a UE identity IE, ameasurement report IE, handoff cell information IE, a cause IE, and aDSC backoff response timer IE.

The UE identity IE may include information suitable for use indetermining identity related information for the wireless device (orUE), such as the international mobile subscriber identity (IMSI) of thewireless device or its network.

The measurement report IE may include the latest, last, or most recentmeasurement report E-UTRAN RRC message received by the lessor networkfor the identified wireless device (i.e., the wireless devices that arerequested to backoff to lessee network).

The bid ID IE may include a bid ID value corresponding to the bid thatsuccessfully participated in and completed/won the auction. The bid IDmay be used to identify the auction/contract associated with the backoffoperations (i.e., the auction/contract for which the resources wereallocated).

In an embodiment, the lessor DSC 144 b may be configured to determinewhether there are multiple bid IDs that correspond to a congested cell.In an embodiment, the lessor DSC 144 b may be configured to select thebid ID value from a plurality of bid IDs in response to determining thatthere are multiple bid IDs that correspond to a congested cell. Invarious embodiments, the lessor DSC 144 b may be configured to selectthe bid ID value based on an operator policy provisioned at the lessorDSC 144 b, based on a previous agreement, based on a policy/rulepreviously negotiated by lessor and lessee network operators, etc.

In operation 1506, the DPC 146 may forward the received DSC BACKOFFCOMMAND message to the lessee DSC 144 a. In operation block 1508, thelessee DSC 144 a may use the information in the UE identity IE of thereceived DSC BACKOFF COMMAND message identify wireless device(s) thatare to be subjected to the backoff operations (i.e., the wirelessdevices that are to be handed back).

In operation block 1510, the lessee DSC 144 a may use the informationincluded in the measurement report IE of the received DSC BACKOFFCOMMAND message to determine, identify, and/or select a target cell(within lessee network) to which the identified wireless device(s) areto be handed over (the lessor network may have previously enabledmeasurement reporting from the wireless devices, such as when theyattached, or were handed over, to the lessor network.)

In operation 1512, the lessee DSC 144 a may generate and send a DSCBACKOFF RESPONSE message to the DPC 146. The lessee DSC 144 a may beconfigured to generate the DSC BACKOFF RESPONSE message to include anyor all of a message type information element (IE), a message ID IE, abid ID IE, a UE identity IE, a handoff cell information IE, and a causeIE. In an embodiment, the lessee DSC 144 a may be configured to generatethe DSC BACKOFF RESPONSE message to include the cause IE (or a value forthe cause IE) in response to determining that a suitable target cell(within lessee network) could not be identified or selected for thehanded over. The value of the cause IE may identify a cause of thefailure, such as network overload, no appropriate target cell found, orunknown wireless device/UE. In an embodiment, the lessee DSC 144 a maybe configured to generate the DSC BACKOFF RESPONSE message to include avalue (e.g., target cell information) for the handoff cell informationIE in response to successfully identifying a target cell (within lesseenetwork) to which the wireless device may be handed over.

In operation 1514, the DPC 146 may identify the lessor DSC 144 a basedon the bid id IE included in the received DSC BACKOFF RESPONSE message,and forward the received DSC BACKOFF RESPONSE message to the lessor DSC144 b. In operation block 1516, the lessor DSC 144 b may determinewhether the received DSC BACKOFF RESPONSE message includes a handoffcell information IE (or a valid value for the handoff cell informationIE). In response to determining that the received DSC BACKOFF RESPONSEmessage includes a handoff cell information IE (or a valid value for thehandoff cell information IE), in operation block 1518, the lessor DSC144 b may use the target cell information included in the handoff cellinformation IE to encode a HANDOVER REQUIRED message. In operation block1520, the lessor DSC 144 b may and initiate S1 based handover procedureto handover the wireless device from lessor network to lessee network.

With reference to FIG. 15B, in operation block 1552, the lessor DSC 144b may determine that the DPC 146 has not responded to the DSC BACKOFFCOMMAND message (sent as part of operation 1504) within a time periodidentified in the DSC backoff response timer IE included in the DSCBACKOFF COMMAND message. Alternatively or additionally, in operationblock 1554, the lessor DSC 144 b may determine that there is significantor severe network congestion or administrative reasons that requirewithdraw of the allocation of all remaining network resources pertainingto the resources/bid id included or identified in the DSC BACKOFFCOMMAND message.

In operation 1556, the lessor DSC 144 b may generate and send a DSCRESOURCES WITHDRAWN message to the DPC 146. In operation 1558, the DPC146 may forward the received DSC RESOURCES WITHDRAWN message to thelessee DSC 144 a to withdraw the allocation of the remaining networkresources. In operation block 1560, the lessee DSC 144 a may performvarious resource withdrawn failure-response operations, such as droppingcalls, determining whether to bid for new resources, etc.

FIG. 16A illustrates an embodiment DSC initiated DSAAP de-registrationmethod 1600 for terminating operations. In the example illustrated inFIG. 16A, the DSC initiated DSAAP de-registration method 1600 isperformed by processing cores in a DPC 146 component and a DSC 144component, each of which may include all or portions of a DSAAPmodule/component.

In operation block 1602, the DSC 144 may determine that it needs toterminate DSA operations. In operation 1604, the DSC 144 may generateand send a DSC DE-REGISTER message to the DPC 146. The DSC 144 may beconfigured to generate the DSC DE-REGISTER message to include any or allof a message type information element (IE), a message ID IE, a backofftimer IE, and a cause IE that identifies a cause for the termination ofoperations. In operation block 1606, the DPC 146 may clear all therelated resources associated with the DSC 144 and/or perform othersimilar operations to de-register the DSC 144 in response to receivingthe DSC DE-REGISTER message.

FIG. 16B illustrates an embodiment DPC initiated DSAAP de-registrationmethod 1650 for terminating operations. In the example illustrated inFIG. 16B, the DPC initiated DSAAP de-registration method 1650 isperformed by processing cores in a DPC 146 component and a DSC 144component, each of which may include all or portions of a DSAAPmodule/component.

In operation block 1652, the DPC 146 may determine that it needs toterminate DSA operations with the DSC 144. In operation 1654, the DPC146 may generate and send a DSC DE-REGISTER message to the DSC 144. TheDPC 146 may be configured to generate the DSC DE-REGISTER message toinclude any or all of a message type information element (IE), a messageID IE, a backoff timer IE, and a cause IE that identifies a cause forthe termination of operations (e.g., overload, unspecified, etc.). Inoperation block 1656, the DPC 146 may clear all the related resourcesassociated with the DSC 144 and/or perform other similar operations tode-register the DSC 144.

In operation block 1658, the DSC 144 may perform various de-registrationfailure response operations based on the information included in thereceived DSC DE-REGISTER message. For example, the DSC 144 may beconfigured to not retry registration to the same DPC 146 for at leastthe duration indicated in the backoff timer IE included in the receivedDSC DE-REGISTER message when the value of the cause IE in the DSCDE-REGISTER message is set to “overload.”

FIG. 17A illustrates a DSC initiated DSAAP error indication method 1700for reporting errors in accordance with an embodiment. In the exampleillustrated in FIG. 17A, method 1700 is performed by processing cores ina DPC 146 component and a DSC 144 component, each of which may includeall or portions of a DSAAP module/component.

In operation block 1702, the DSC 144 may detect an error or errorcondition (e.g., a protocol error, etc.). In operation 1704, the DSC 144may generate and send an ERROR INDICATION message to the DPC 146. TheDSC 144 may be configured to generate the ERROR INDICATION message toinclude any or all of a message type information element (IE), a messageID IE, cause IE, and a criticality diagnostics IE. The cause IE mayinclude information suitable for use in identifying a cause or type ofthe error (e.g., transfer syntax error, abstract syntax error, logicalerror, etc.). The criticality diagnostics IE may include a procedurecode IE, a triggering message IE, and a procedure criticality IE. Inoperation block 1706, the DSC 144 and/or DPC 146 may perform variouserror-response operations based on the detected error or informationincluded in the received ERROR INDICATION message. The error detectionand response operations are discussed in detail further below.

FIG. 17B illustrates an embodiment DPC initiated DSAAP error indicationmethod 1750 for reporting errors in accordance with another embodiment.In the example illustrated in FIG. 17B, method 1750 is performed byprocessing cores in a DPC 146 component and a DSC 144 component, each ofwhich may include all or portions of a DSAAP module/component.

In operation block 1752, the DPC 146 may detect an error condition. Inoperation 1754, the DPC 146 may generate and send an ERROR INDICATIONmessage to the DSC 144. The DPC 146 may be configured to generate theERROR INDICATION message to include a cause information element (IE)that identifies a cause for the error. In operation block 1756, the DSC144 and/or DPC 146 may perform various error-response operations basedon the information included in the received ERROR INDICATION message.

As mentioned above, the DSC 144 and DPC 146 may be configured performvarious error-response or failure response operations in response todetecting an error or failure condition. As part of these operations,the DSC 144 and/or DPC 146 may identify the type or cause of theerror/failure condition, and tailor their responses based on theidentified type or cause. For example, the DSC 144 and/or DPC 146 may beconfigured to determine whether a detected error is a protocol error,and tailor their responses accordingly.

Protocol errors include transfer syntax errors, abstract syntax errors,and logical errors. A transfer syntax error may occur when the receivingfunctional DSAAP entity (e.g., DSC, DPC, etc.) is not able to decode thereceived physical message. For example, transfer syntax errors may bedetected while decoding ASN.1 information in a received message. In anembodiment, the DSC 144 and DPC 146 components may be configured toretransmit or re-request a DSAAP message in response to determining thata detected error is a transfer syntax error (e.g., as part of theerror-response operations).

An abstract syntax error may occur when the receiving functional DSAAPentity (e.g., DSC, DPC, etc.) receives information elements (IEs) or IEgroups that cannot be comprehended or understood (i.e., an unknown IEid). An abstract syntax error may also occur when the entity receives aninformation element (IE) for which a logical range (e.g., allowed numberof copies) is violated. The DSC 144 and DPC 146 components may beconfigured to detect or identify these types of abstract syntax errors(i.e., cannot comprehend abstract syntax error), and in response,perform error-response operations based on criticality informationincluded in the corresponding DSAAP message. Additional detailsregarding these operations and the criticality information are providedfurther below.

An abstract syntax error may also occur when the receiving functionalDSAAP entity does not receive IEs or IE groups, but according to thespecified presence of the object, the IEs or IE groups should have beenpresent in the received message. The DSC 144 and DPC 146 components maybe configured to detect or identify these particular types of abstractsyntax errors (i.e., missing IE or IE group), and in response, performerror-response operations based on criticality information and presenceinformation for the missing IE/IE group. Additional details regardingthese operations, criticality information, and presence information areprovided further below.

An abstract syntax error may also occur when the receiving entityreceives IEs or IE groups that are defined to be part of that message inwrong order or with too many occurrences of the same IE or IE group. Inaddition, an abstract syntax error may also occur when the receivingentity receives IEs or IE groups, but according to the conditionalpresence of the concerning object and the specified condition, the IEsor IE groups should not have been present in the received message. TheDSC 144 and DPC 146 components may be configured to detect or identifysuch abstract syntax errors (i.e., wrong order, too many occurrences,erroneously present, etc.), and in response, reject or terminate aprocedure or method associated with the error (e.g., the method thatcaused the error). The DSC 144 and DPC 146 components may reject orterminate the procedure/method as part of the error-response operations.

In the various embodiments, the DSC 144 and DPC 146 components may beconfigured to continue to decode, read, or process a DSAAP message afterdetecting, identifying, or determining that an abstract syntax erroroccurred for that message. For example, the DSC 144 and DPC 146components may skip a portion of the message that includes an error, andcontinue processing the other portions of the message. As part of thiscontinued processing, the DSC 144 and DPC 146 components may detect oridentify additional abstract syntax errors.

In an embodiment, the DSC 144 and DPC 146 components may be configuredto perform error-response operations for each detected abstract syntaxerror and/or based on the criticality information and presenceinformation for the IE/IE group associated with the abstract syntaxerror.

As mentioned above, each DSAAP message may include, or may be associatedwith, criticality information, presence information, range information,and assigned criticality information. In the various embodiments, areceiving functional DSAAP entity (e.g., DSC, DPC, etc.) may beconfigured to use any or all of such information (e.g., criticalityinformation, presence information, etc.) when detecting an error,identifying the type of the error, or the specific error-response thatare to be performed. That is, the entity may perform differentoperations depending on the values of the criticality information,presence information, range information, and/or assigned criticalityinformation.

In an embodiment, the receiving functional DSAAP entity (e.g., DSC, DPC,etc.) may be configured to use the presence information included in aDSAAP message when identifying the type of error and the specificerror-response operations that are to be performed for the identifiederror type. For example, the entity may use the presence information todetermine whether the presence of an information element (IE) isoptional, conditional, or mandatory (e.g., with respect to RNSapplication) for that message or communication. The entity may determinethat an abstract syntax error has occurred when a received message ismissing one or more information elements that are determined to bemandatory (or conditional when the condition is true).

In an embodiment, the receiving functional DSAAP entity (e.g., DSC, DPC,etc.) may be configured use the criticality information when identifyingthe specific error-response operations that are to be performed. Thatis, each DSAAP message may include criticality information for eachindividual information element (IE) or IE group included in thatmessage. The values of criticality information for each IE or IE groupmay include “Reject IE,” “Ignore IE and Notify Sender,” and “Ignore IE.”The receiving entity (e.g., DSC, DPC, etc.) may use this criticalityinformation to determine that an IE, an IE group, or an EP isincomprehensible, identify the condition as an abstract syntax error(i.e., a cannot comprehend abstract syntax error), and/or to identifythe error-response operations that are to be performed (e.g., reject,ignore, notify, etc.).

In an embodiment, the receiving entity (e.g., DSC, DPC, etc.) may beconfigured to reject a method/procedure and initiate a DSAAP errorindication method (discussed above with reference to FIGS. 17A-B) inresponse to determining that an information element (IE) included in amessage received during the performance of that method/procedure isincomprehensible, and that value of the criticality information for thatIE is set to “Reject IE.”

For example, when a message that initiates a method/procedure (e.g., aDSC REGISTER REQUEST message, etc.) is received, determined to includeone or more IEs/IE groups that are incomprehensible and marked as“Reject IE,” the receiving entity may the reject the method/procedure bynot executing any of the functional requests included in that message.The receiving entity may also report the rejection of one or more IEs/IEgroups using the message normally used to report unsuccessful outcome ofthe procedure. When the information in the received initiating messageis insufficient and cannot be used to determine a value for all IEs thatare required to be present in the message used to report theunsuccessful outcome of the procedure, the receiving entity mayterminate the procedure and initiate a DSAAP error indicationmethod/procedure.

As a further example, when a message initiating a method/procedure thatdoes not have a message to report unsuccessful outcome is received, andthat message includes one or more IEs/IE groups marked with “Reject IE”which the receiving entity does not comprehend, the receiving entity mayterminate the method/procedure and initiate a DSAAP error indicationmethod/procedure.

As yet another example, when a response message (e.g., a DSC REGISTERRESPONSE message, etc.) is received that includes one or more IEs markedwith “Reject IE” which the receiving entity does not comprehend, thereceiving entity may consider the method/procedure as beingunsuccessfully terminated, and initiate a local error handling method.

In an embodiment, the receiving entity (e.g., DSC, DPC, etc.) may beconfigured to ignore or skip a method/procedure and initiate an DSAAPerror indication method (discussed above with reference to FIGS. 17A-B)in response to determining that an information element (IE) included ina message received during the performance of that method/procedure isincomprehensible, and that value of the criticality information for thatIE is set to “Ignore IE and Notify Sender.”

As an example, when a message initiating a method/procedure is receivedcontaining one or more IEs/IE groups marked with “Ignore IE and NotifySender” which the receiving entity does not comprehend, the receivingentity may ignore the content of the incomprehensible IEs/IE groups,continue with the method/procedure as if the incomprehensible IEs/IEgroups were not received (except for the reporting) using thecomprehended IEs/IE groups, and report in the response message of themethod/procedure that one or more IEs/IE groups have been ignored. Whenthe information received in the initiating message is insufficient todetermine a value for all IEs that are required to be present in theresponse message, the receiving entity may terminate themethod/procedure and initiate a DSAAP error indication method/procedure.

As a further example, when a message initiating a method/procedure thatdoes not have a message to report the outcome of the method/procedure isreceived containing one or more IEs/IE groups marked with “Ignore IE andNotify Sender” which the receiving entity does not comprehend, thereceiving entity may ignore the content of the not comprehended IEs/IEgroups, continue with the method/procedure as if the not comprehendedIEs/IE groups were not received (except for the reporting) using theunderstood IEs/IE groups, and initiate a DSAAP error indicationmethod/procedure to report that one or more IEs/IE groups have beenignored.

As yet another example, when a response message is received containingone or more IEs/IE groups marked with “Ignore IE and Notify Sender”which the receiving entity does not comprehend, the receiving entity mayignore the content of the not comprehended IE/IE groups, continue withthe method/procedure as if the not comprehended IEs/IE groups were notreceived (except for the reporting) using the understood IEs/IE groupsand initiate a DSAAP error indication method/procedure.

In an embodiment, the receiving entity (e.g., DSC, DPC, etc.) may beconfigured to ignore or skip a method/procedure in response todetermining that an information element (IE) included in a messagereceived during the performance of that method/procedure isincomprehensible, and that value of the criticality information for thatIE is set to “Ignore IE.”

As an example, when a message initiating a method/procedure is receivedcontaining one or more IEs/IE groups marked with “Ignore IE” which thereceiving entity does not comprehend, the receiving entity may ignorethe content of the not comprehended IEs/IE groups and continue with themethod/procedure as if the not comprehended IEs/IE groups were notreceived using only the understood IEs/IE groups.

As a further example, when a response message is received that includesone or more IEs/IE groups marked with “Ignore IE” which the receivingentity does not comprehend, the receiving entity may ignore the contentof the not comprehended IEs/IE groups and continue with themethod/procedure as if the not comprehended IEs/IE groups were notreceived using the understood IEs/IE groups.

When reporting not comprehended IEs/IE groups marked with “Reject IE” or“Ignore IE and Notify Sender” using a response message defined for themethod/procedure, the Information Element Criticality Diagnostics IE maybe included in the Criticality Diagnostics IE for each reported IE/IEgroup.

In an embodiment, the receiving entity (e.g., DSC, DPC, etc.) may beconfigured to initiate a DSAAP error indication method (discussed abovewith reference to FIGS. 17A-B) in response to determining that it cannotdecode a type of message IE in a received message. In an embodiment, theentity may be configured to only consider the IEs specified in thespecification version used by the component when determining the correctorder for the IE included in a message.

In an embodiment, the receiving entity (e.g., DSC, DPC, etc.) may beconfigured to treat the missing IE/IE group according to the criticalityinformation for the missing IE/IE group in the received messagespecified in the version of the present document used by the receiver.

As an example, the receiving entity (e.g., DSC, DPC, etc.) may beconfigured to not execute any of the functional requests of a receivedinitiating message in response to determining that the received messageis missing one or more IEs/IE groups with specified criticality “RejectIE.” The receiving entity may reject the method/procedure and report themissing IEs/IE groups using the message normally used to reportunsuccessful outcome of the method/procedure. When it is determined thatthe information received in the initiating message was insufficient todetermine a value for all IEs that are required to be present in themessage used to report the unsuccessful outcome of the method/procedure,the receiving entity may terminate the method/procedure and initiate aDSAAP error indication method/procedure.

As a further example, when a received message initiating amethod/procedure that does not have a message to report unsuccessfuloutcome is missing one or more IEs/IE groups with specified criticality“Reject IE”, the receiving entity may terminate the method/procedure andinitiate a DSAAP error indication method/procedure.

As yet another example, when a received response message is missing oneor more IEs/IE groups with specified criticality “Reject IE, thereceiving entity may consider the method/procedure as unsuccessfullyterminated and initiate a local error handling method/procedure.

As another example, when a received message initiating amethod/procedure is missing one or more IEs/IE groups with specifiedcriticality “Ignore IE and Notify Sender”, the receiving entity mayignore that those IEs are missing and continue with the method/procedurebased on the other IEs/IE groups present in the message and report inthe response message of the method/procedure that one or more IEs/IEgroups were missing. When the information received in the initiatingmessage is insufficient to determine a value for all IEs that arerequired to be present in the response message, the receiving entity mayterminate the method/procedure and initiate a DSAAP error indicationmethod/procedure.

As another example, when a received message initiating amethod/procedure that does not have a message to report the outcome ofthe method/procedure is missing one or more IEs/IE groups with specifiedcriticality “Ignore IE and Notify Sender”, the receiving entity mayignore that those IEs are missing and continue with the method/procedurebased on the other IEs/IE groups present in the message and initiate aDSAAP error indication method/procedure to report that one or moreIEs/IE groups were missing.

As another example, when a received message a received response messageis missing one or more IEs/IE groups with specified criticality “IgnoreIE and Notify Sender”, the receiving entity may ignore that those IEsare missing and continue with the method/procedure based on the otherIEs/IE groups present in the message and initiate a DSAAP errorindication method/procedure to report that one or more IEs/IE groupswere missing.

As another example, when a received message initiating amethod/procedure is missing one or more IEs/IE groups with specifiedcriticality “Ignore IE”, the receiving entity may ignore that those IEsare missing and continue with the method/procedure based on the otherIEs/IE groups present in the message.

As another example, when a received response message is missing one ormore IEs/IE groups with specified criticality “Ignore IE”, the receivingentity may ignore that those IEs/IE groups are missing and continue withthe method/procedure based on the other IEs/IE groups present in themessage.

The receiving entity (e.g., DSC, DPC, etc.) may be configured to respondto messages that include IEs or IE groups that received in wrong order,include too many occurrences, or are erroneously present (i.e., areincluded and marked as “conditional” when the condition is not met) invarious ways. For example, the receiving entity (e.g., DSC, DPC, etc.)may be configured to not execute any of the functional requests of areceived initiating message in response to determining that the receivedmessage includes IEs or IE groups in wrong order, includes too manyoccurrences of an IE, or includes erroneously present IEs. The receivingentity may reject the method/procedure and report the cause value“Abstract Syntax Error (Falsely Constructed Message)” using the messagenormally used to report unsuccessful outcome of the method/procedure.When the information received in the initiating message is insufficientto determine a value for all IEs that are required to be present in themessage used to report the unsuccessful outcome of the method/procedure,the receiving entity may terminate the method/procedure and initiate aDSAAP error indication method/procedure.

As another example, when a message initiating a method/procedure thatdoes not have a message to report unsuccessful outcome is receivedcontaining IEs or IE groups in wrong order or with too many occurrencesor erroneously present, the receiving entity may terminate themethod/procedure, and initiate a DSAAP error indication method/procedureusing the cause value “Abstract Syntax Error (Falsely ConstructedMessage)”.

As another example, when a response message is received containing IEsor IE groups in wrong order or with too many occurrences or erroneouslypresent, the receiving entity may consider the method/procedure asunsuccessfully terminated and initiate local error handling.

As mentioned above, protocol errors include transfer syntax errors,abstract syntax errors, and logical errors. A logical error occurs whena message is comprehended correctly, but the information containedwithin the message is not valid (i.e. semantic error), or describes amethod/procedure which is not compatible with the state of the receivingentity.

In an embodiment, a receiving entity (e.g., DSC, DPC, etc.) may beconfigured to perform error response operations based on the class ofthe method/procedure and irrespective of the criticality information ofthe IE's/IE groups containing the erroneous values in response todetermining/detecting an logical error.

For example, when a logical error is detected in a request message of aclass 1 method/procedure, and the method/procedure has a message toreport this unsuccessful outcome, this message may be sent with anappropriate cause value (i.e., in the clause IE), such as “semanticerror” or “message not compatible with receiver state.” When a logicalerror is detected in a request message of a class 1 method/procedure,and the method/procedure does not have a message to report thisunsuccessful outcome, the method/procedure may be terminated and a DSAAPerror indication method/procedure may be initiated with an appropriatecause value. Where the logical error exists in a response message of aclass 1 procedure, the procedure may be considered as unsuccessfullyterminated and local error handling may be initiated.

When a logical error is detected in a message of a class 2 procedure,the procedure may be terminated and a DSAAP error indication proceduremay be initiated with an appropriate cause value.

In the various embodiments, the receiving entity (e.g., DSC, DPC, etc.)may be configured to perform a local error handling method/procedure (asopposed to a DSAAP error indication method/procedure) when a protocolerror is detected in the ERROR INDICATION message. In case a responsemessage or error indication message needs to be returned, but theinformation necessary to determine the receiver of that message ismissing, the procedure may be considered as unsuccessfully terminatedand local error handling may be initiated. When an error that terminatesa procedure occurs, the returned cause value may reflect the error thatcaused the termination of the procedure even if one or more abstractsyntax errors with criticality “ignore and notify” have earlier occurredwithin the same procedure.

FIG. 18 illustrates the operations and information flows between variouscomponents when performing a DSA resource update method 1800 inaccordance with an embodiment. In the example illustrated in FIG. 18,the operations of DSA resource update method 1800 are performed byvarious components, including a wireless device 102, a first eNodeB 116a, a first S-GW 118 a, a first DSC 144 a, a DPC 146, a second DSC 144 b,a second S-GW 118 b, and a second eNodeB 116 b. The first eNodeB 116 a,first S-GW 118 a, and first DSC 144 a are included in a first network(i.e., a lessee network). The second DSC 144 b, second S-GW 118 b, andsecond eNodeB 116 b are included in a second network (i.e., a lessornetwork).

In operation 1802, the wireless device 102 may attach to the lesseenetwork. In operation 1804, the first eNodeB 116 a may monitor andreport resource usages and node level congestion levels to the first DSC114 a. This may be accomplished by the first eNodeB 116 a generating andsending a resource update message to the first DSC 144 a, eitherdirectly (e.g., via the Xe interface) or via the first S-GW 118 a (e.g.,via the S1-U interface). In an embodiment, the first eNodeB 116 a maygenerate the resource update message to include information suitable forreporting resource usage level for multiple cells, including the cell towhich the wireless device 102 is attached. In various embodiments, thefirst eNodeB 116 a may be configured to send such resource updatemessages periodically or in response to detecting a condition or event(e.g., new wireless device attached, etc.).

In operation 1806, the first S-GW 118 a may use the information includedin the received resource update message to update its resource usagerecords and/or forward the resource update message to the DSC 144 a. Inoperation 1808, the first S-GW 118 a may start a resource updateacknowledgment timer. In operation 1810, the first DSC 144 a, maygenerate and send a resource update acknowledgment message to the firsteNodeB, either directly or via the first S-GW 118 a. In operation 1812,the first S-GW 118 a may forward the resource update acknowledgmentmessage to the first eNodeB 116 a and/or use the information included inthe received acknowledgment message to update its resource usagerecords. In operation 1814, the first S-GW 118 a may stop the resourceupdate acknowledgment timer in response to receiving the acknowledgmentmessage and/or in response to determining that the resource updateacknowledgment message was received prior the expiration of the resourceupdate acknowledgment timer.

In operations 1816-1822, the first eNodeB 116 a may periodically reportusage/congestion levels and the first DSC 114 a and first S-GW 118 a mayupdate their resource usage records, which may be accomplished byperforming the same or similar operations as those performed inoperations 1804-1814. Similarly, in operations 1850-1866, the secondeNodeB 116 b, second DSC 114 b, and second S-GW 118 b may perform thesame or similar operations as those performed as part of operations1804-1822.

In operations 1824 and 1826, the first DSC 114 a may determine whetherthere are excess resources available in the first network for allocationto other networks, and send a resource availability message to the DPC146. The resource availability message may include information suitablefor informing the DPC 146 of the resources determined to be availablefor allocation. The DPC 146 may be configured to receive, store, ormaintain resource availability information for multiple DSCs and/or formultiple different networks (i.e. different PLMN-IDs).

In operation 1828, the first DSC 114 a may start a timer. In operations1830 and 1832, the first DSC 114 a may initiate or participate in anauction by monitoring its available/remaining resources and sendingresource availability advertisements to DPC 1830. In operation 1834, thefirst DSC 114 a may determine that the timer expired, and discontinueadvertizing its resources. In operations 1870-1880, the second DSC 114 bmay perform the same or similar operations as those performed as part ofoperations 1824-1834.

FIG. 19 illustrates an embodiment DSA method 1900 of allocatingresources in a first communication network for access and use by asecond communication network. The operations of DSA method 1900 may beperformed by a processing core of a DPC 146 component.

In operation 1902, a DPC 146 component may establish a communicationlink to a DSC 144 a in first communication network. In operation 1904,the DPC 146 may determine whether a telecommunication resource of thefirst communication network is available for allocation based oninformation received via the communication link. In an embodiment, theDPC 146 may determine that the telecommunication resource is availablefor allocation at a future date and time.

In operation 1906, the DPC 146 may broadcast a communication signal thatincludes information suitable for informing a plurality of communicationnetworks that the telecommunication resource is available for allocationvia an auction and including an auction start time for the auction. Inoperation 1908, the DPC 146 may receive bids from the plurality ofcommunication networks for the telecommunication resource determined tobe available for allocation in response to broadcasting thecommunication message and after the auction start time included in thebroadcast communication signal. In an embodiment, receiving bids fromthe plurality of communication networks may include receiving bids foraccess and use of the telecommunication resource determined at thefuture date and time.

In operation 1910, the DPC 146 may accept only the bids received fromauthorized networks determined to be eligible to participate in theauction. For example, the DPC 146 may determine whether thetelecommunication resource is compatible with each of the plurality ofcommunication networks, authorize networks in the plurality ofcommunication networks as being eligible to participate in the auctionbased on their compatibility with the telecommunication resource, andaccept bids from only the authorized networks.

In operation 1912, the DPC 146 may allocate the telecommunicationresource of the first communication network for access and use by asecond communication network in the plurality of communication networksbased on accepted bids. In an embodiment, allocating thetelecommunication resource may include allocating the telecommunicationresource of the first communication network for access and use by thesecond communication network at the future date and time. In operation1914, the DPC 146 may send a communication message to the secondcommunication network that includes information suitable for informingthe second communication network that use of allocated telecommunicationresource may begin. In operation 1916, the DPC 146 may record atransaction in a transaction database identifying the telecommunicationresource as being allocated for use by the second communication network.

In operation 1918, the DPC 146 may request return of the allocatedtelecommunication resource. In operation 1920, the DPC 146 may broadcasta second communication signal to inform the plurality of communicationnetworks that the telecommunication resource is available forreallocation via a second auction.

FIG. 20A illustrates another embodiment DSA method 2000 of allocatingresources in a first communication network for access and use by asecond communication network. The operations of DSA method 2000 may beperformed by a processing core of a DPC 146 component.

In block 2002, the DPC 146 component may establish a communication linkto a DSC 144 a in first communication network. In block 2004, the DPC146 component may determine that a resource in a first communicationnetwork is available for allocation. In block 2006, the DPC 146component may broadcast a first communication signal informing aplurality of communication networks that the resource is available forallocation and of a geographical area associated with the resource. Inblock 2008, the DPC 146 component may allocate the resource of the firstcommunication network for access and use by a second communicationnetwork in the plurality of communication networks. In block 2010, theDPC 146 component may broadcast a second communication signal informingthe second communication network that use of allocated telecommunicationresource may begin in the geographical area. In block 2012, the DPC 146component may record a transaction in a transaction database identifyingthe telecommunication resource as being allocated for use by the secondcommunication network.

In operation 2014, the DPC 146 component may request return of theallocated telecommunication resource. In operation 2016, the DPC 146 maybroadcast a second communication signal to inform the plurality ofcommunication networks that the telecommunication resource is availablefor reallocation via a second auction.

In an embodiment, the DSA method 2000 may further include the DPC 146component receiving resource configuration information relating to aresource allocation scheme from a first DSC 144 in the firstcommunication network and sending the resource configuration informationto a second DSC 144 in the second communication network. In a furtherembodiment, the DSA method 2000 may include the DPC 146 componentreceiving coordination information relating to availability of thetelecommunication resource based on geographical areas from the firstDSC 144 and sending the coordination configuration information to thesecond DSC 144.

In a further embodiment, the DPC 146 component may be configured tonegotiate a resource leasing scheme between the first and secondcommunication networks for a use of the resource, and coordinating ahandover of a mobile device between the first and second communicationnetworks based on geographic boundaries defined in the resource leasingscheme. The DPC 146 may be further configured to determine the validityof a subscriber device (e.g., wireless device 102) of the secondcommunication network based on the proximity of the subscriber device tothe geographical area, level of quality of service available to thesubscriber device, and/or information included in the resource leasingscheme.

In various embodiments, the DPC 146 may be configured to instruct thesubscriber device to change networks or to establish a communicationlink to a resource in the first communication network based on theproximity of the subscriber device to the geographical area, level ofquality of service available to the subscriber device, and/or terms ofthe resource leasing scheme. The DPC 146 may be configured to instruct asubscriber device that is actively connected to or using thetelecommunication resource to change networks and/or to attach toanother resource based on the proximity of the subscriber device to thegeographical area.

In an embodiment, the DSA system may include a first DSC may includefirst DSC processor that is coupled to the DPC via a first communicationlink (i.e., a wired or wireless link), and the second DSC may include asecond DSC processor coupled to the DPC via a second communication link.In addition, each of the first and second DSCs may be coupled to aneNodeB. For example, the second DSC may be coupled to an eNodeB in thesecond telecommunication network via third communication link. The firstand second communication links may be defined over the Xd interface, andthe third communication link may be defined over the Xe interface. Thatis, the DSCs may communicate with the DPC via the Xd interface by usingthe DSAAP protocol, and the DSCs may communicate with the eNodes intheir respective networks via the Xe interface by using the DSAAPprotocol.

In an embodiment, the eNodeB processor may be configured monitor networkconditions, generate reports based on a result of the monitoring, andsend the generated reports to the second DSC via the third communicationlink. This may be accomplished by using the DSAAP protocol (i.e., bysending/receiving DSAAP communication messages and/or performing any ofDSAAP methods discussed in this application). In an embodiment,monitoring network conditions may include monitoring one of networkcongestion, resource usage, and resource availability in the secondtelecommunication network.

In an embodiment, the second DSC processor may be configured to receivethe generated reports from the eNodeB via the third communication link(using the DSAAP protocol), and use information included in the receivedreports to determine whether there are excess network resources in thesecond telecommunication network that are available for allocation anduse by wireless devices in the first telecommunication network.

In an embodiment, the second DSC processor may be configured todetermining a geographical boundary that is associated with a resource,and send information identifying the determined geographical boundary tothe eNodeB via the third communication link (e.g., via a DSAAP componentin the second DSC sending DSAAP messages and/or performing DSAAPmethods).

In an embodiment, the DPC processor may be configured to communicatewith the second DSC and at least one other DSC component using the DSAAPprotocol. As part of these communications, the DPC may receiveinformation suitable for identifying the resources that available forallocation in a plurality of different networks, including the secondtelecommunication network and at least one other telecommunicationnetwork. The DPC processor may use the received information to pool theresources available in the different networks, and communicate with thefirst DSC via the first communication link to allocate a portion of thepool of resources for access and use by wireless devices in the firsttelecommunication network.

In an embodiment, the DPC processor may be configured to receive usertraffic and resource usage information from the second DSC via thesecond communication link (e.g., using the DSAAP protocol), use thereceived information to monitor traffic and resource usage in the secondtelecommunication network, and communicate with the first DSC via thefirst communication link to allocate resources of the secondtelecommunication network to the first telecommunication network. TheDPC may allocate the resources based on the results of the monitoringoperations (i.e., based on detected user traffic and resource usagelevels).

In an embodiment, the DPC processor may be configured to receive bidinformation from the first DSC via the first communication link (usingthe DSAAP protocol), and send bid notification information to the firstDSC via the first communication link.

In an embodiment, the DPC processor may be configured to receiveregistration information from the first DSC via the first communicationlink, use the received registration information to authenticate thefirst DSC, store a DSC identifier in a registration memory of the DPC inresponse to authenticating the first DSC. The DPC processor may alsogenerate a registration accept message that includes a plurality ofinformation elements, and send the generated registration accept messageto the first DSC via the first communication link by using the DSAAPprotocol (e.g., via a DSAAP component in the DPC sending DSAAP messageto the first DSC and/or the DPC and first DSC performing a DSAAPmethod). In an embodiment, the DPC processor may be configured togenerate the registration accept message to include a XEh signalingtransport network layer (TNL) address information element that includesan address value that is suitable for use in establishing to transportlayer session. In an embodiment, the first DSC processor may beconfigured to receive the registration accept message from the DPC viathe first communication link using the DSAAP protocol, and use theaddress value included in the XEh signaling TNL address informationelement of the received registration message to establish a transportlayer session send an invoice to the first DSC via the firstcommunication link using the DSAAP protocol.

In an embodiment, the second DSC processor may be configured todetermine whether there are resources available for allocation withincells serviced by the second DSC, generate a resource register requestmessage in response to determining that there are resources availablefor allocation within the cells serviced by the second DSC, and send thegenerated resource register request message to the DPC via the secondcommunication link using the DSAAP protocol. The DPC processor may beconfigured to receive the resource register request message from thesecond DSC via the second communication link using the DSAAP protocol,rejecting the received resource register request message in responsedetermining that there is insufficient memory to store and serviceresources identified in the received resource register request message,and send a resource register request reject message to the second DSCvia the second communication link using the DSAAP protocol in responseto rejecting the received resource register request message.

In an embodiment, the first DSC processor may be configured to generatean available bids request message, send the generated available bidsrequest message to the DPC via the second communication link, andreceive information on the resources that have been made available forallocation by the second telecommunication network from the DPC inresponse to sending the generated available bids request message. In afurther embodiment, the first DSC processor may be configured togenerate the available bids request message to include a public landmobile network identifier (PLMN-ID) of the second telecommunicationnetwork, and to request a specific resource (e.g., a specific RFfrequency resource, an eNodeB in a specific cell, etc.) from the secondtelecommunication network.

In an embodiment, the DPC processor may be configured to receive a bidrequest message from the first DSC via the first communication link. Thebid request message may include including a bid. The DPC processor maydetermine whether the bid is valid by determining whether the bidcomplies with a requirement of the second telecommunication network. TheDPC processor may sending a bid accept message to the first DSC via thefirst communication link in response to determining that the bid isvalid or send a bid reject message to the first DSC via the firstcommunication link in response to determining that the bid is not valid.

In an embodiment, the second DSC processor may be configured tocommunicate with the DPC to allocate resources of a cell in the secondtelecommunication network for access and use by wireless devices of thefirst telecommunication network, monitor cell traffic to determinewhether the cell is congested, and sending a backoff command message tothe DPC via the second communication link using the DSAAP protocol inresponse to determining that the cell is congested. The backoff commandmessage may include information that is suitable for causing the DPC toinstruct the first DSC to selectively handover the wireless devicesubscribers of the first telecommunication network that using theallocated resources of the cell in the second telecommunication network.The DPC processor may be configured to receive the backoff commandmessage from the second DSC, and communicate with the first DSC usingthe DSAAP protocol so as to cause the first DSC to select a target cellin the first telecommunication network to handoff the wireless devicesusing the allocated resources of the cell.

The various embodiments may include or use a dynamic spectrum arbitrageapplication part (DSAAP) protocol and/or component that is configured toallow, facilitate, support, or augment communications between two ormore DSA components (e.g., DPC, DSC, eNodeB, MME, HSS, etc.) so as toimprove the efficiency and speed of the DSA system. A DSA component maybe any component discussed in this application and/or any component thatparticipates in any of the DSA operations, communications, or methodsdiscussed in this application. As such, the DSAAP component(s) may beconfigured to allow, facilitate, support, or augment communicationsbetween any of the components discussed in this application, includingthe communications between a DPC component and a DSC component, betweenthe DSC component and an eNodeB component, between the DSC component andan MME component, between the DSC component and an HSS component,between the MME component and the HSS component, between the eNodeBcomponent and a wireless device, etc.

To facilitate the communications between two or more DSA components, theDSAAP component(s) may publish application programming interfaces (API)and/or include client modules that facilitate communications between theDSA components. In addition, the DSAAP component(s) may be configured toallow the DSA components to communicate specific information, usespecific communication messages, and/or perform specific operations thattogether provide various DSA functions that further improve theefficiency and speed of the DSA system and participating networks.

As an example, the DSAAP component(s) may be configured to allow aneNodeB to communicate with a DSC component (e.g., via Xe interface 2215and 2217 illustrated in FIG. 22, Xe interface 2423 illustrated in FIG.24, and Xe interface 2627 illustrated in FIG. 26), with other eNodeBs(e.g., via an X2 interface), and with various other components (e.g.,via the S1 interface). As a further example, the DSAAP component(s) maybe configured to allow, facilitate, support, or augment communicationsbetween DSC component(s) and the DPC component so as to allow the DPCand/or DSC components to better pool resources across the differentnetworks, better monitor traffic and resource usage in the variousnetworks, to more efficiently communicate bids and bidding information,to quickly and efficiently register and deregister components, andbetter perform backoff operations (e.g., handover wireless devices 102from lessor network back to lessee network) and/or handin (e.g.,handover wireless devices 102 from lessee network to lessor network)operations. The DSAAP component(s) may also improve the DSA resourceauctioning operations by improving the performance and efficiency of theprocedures for bidding, generating invoices, advertizing resources,requesting resources, purchasing resources, validating bid credentials,etc.

In the various embodiments, all or portions of the DSAAP component maybe included in one or more DSA components, such as a DPC component, aDSC component, an eNodeB component, an MME component, and an HSScomponent. The DSAAP component may be implemented in hardware, software,or a combination of hardware and software. In an embodiment, the DSAAPcomponent may be configured to implement a DSAAP protocol, which may bedefined over the Xe, Xd, and/or X2 reference points. In variousembodiments, the Xe reference point between DSC and eNodeB may use theDSAAP protocol, TR-069 protocol, and/or TR-192 data model extensions tosupport listing available resources at the eNodeB and notifying theeNodeB of bid/buy confirmations. The Xd reference point between DSC andDPC may use the DSAAP protocol for dynamic spectrum and resourcearbitrage operations. The X2 interface/reference point between theeNodeBs may also use the DSAAP protocol to communicate information.

In various embodiments, the DSAAP component(s) may be configured toallow the various DSA components (e.g., DSC, DPC, eNodeB, etc.) tocommunicate using the DSAAP protocol and/or to perform various DSAAPmethods. DSAAP methods may be performed in any of the DSA systemsdiscussed in this application, such as a system that includes a firstDSC server in a first telecommunication network (e.g., a lesseenetwork), a second DSC server in second telecommunication network (e.g.,a lessor network), and a DPC server that is outside of the first andsecond telecommunication networks.

In further embodiments, the Dynamic Spectrum Arbitrage (DSA) system maybe configured to enable the dynamic leasing of excess LTE networkcapacity through efficient mobility management via DSAFlex (e.g., viaarranging or configuring the DSA components to perform one or moreDSAFlex operations, etc.). For example, a dynamic spectrum arbitrage(DSA) system may be configured to perform DSAFlex, which may include aDSA component (e.g., a processor in a DCS component in the lessornetwork, etc.) broadcasting a communication message that includesinformation advertising that a telecommunication resource in a firsttelecommunication network is available for allocation and use bywireless devices in a second telecommunication network, deter mininglease criteria parameters of a resource lease associated with theadvertised telecommunication resource, determining network capability ofthe second telecommunication network, selecting one of a DSA Litenetwork configuration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria, determining configuration parameters (e.g.,configuration parameters that match a specific OEM format, etc.) for oneor more nodes in each of the first and second telecommunication networksbased on the selected network configuration, and sending the determinedconfiguration parameters to directly or indirectly to components in eachof the first and second networks (e.g., in their respective OEM formats,etc.).

The DSA component may select the DSAX network configuration (based ondetermined network capability and determined lease criteria), select asuitable interface(s), and send the determined configuration parameterdirectly to the components in the first and second networks. Forexample, the DSA component may send the configuration parameters to aneNodeB via an Xe interface and to an MME component via an Xm interface.The DSA component may also select the DSA Lite network configuration orthe DSA9 network configuration, in which case it may send the determinedconfiguration parameters to an O&M component in each of the first andsecond networks (i.e., components in the lessee and lessor networks).

In some embodiments, the DSA component may be configured to dynamicallyselect an interface (e.g., Xe, Xm, etc.) based on the determined networkcapabilities of the networks. In some embodiments, the DSA component maybe configured to perform various operations for routing traffic todestination components that are selected based on the determined networkconfiguration (e.g., configuration of the lessee network, etc.).

In some embodiments, the DSA component may be a dynamic spectrumcontroller (DSC) component that includes a DSC processor. The DSAcomponent may be configured to receive a list of resources that areavailable for bidding (via a communication link to a dynamic spectrumpolicy controller component that includes a DPC processor), generate abid request message that includes information suitable for bidding on aresource identified in the received list of resources, and send thegenerated bid request message to the DPC via the communication link. TheDPC may be configured to start a bid timer, receive a bid requestmessage (from the DSC), determine whether the bid request message isvalid, send a bid accept message to the DSC via the communication linkin response to determining that the bid is valid, determine whether thebid timer has expired, determine whether the DSC is a winner bidder thatis to be allocated the resource based on information included in the bidrequest message in response to determining that the bid request messageis valid and that the bid timer has expired, and send a bid won messageto the DSC via the communication link in response to determining thatthe DSC is the winner bidder.

FIG. 20B illustrates a method 2050 of performing dynamic spectrumarbitrage (DSA) that include DSAFlex operations in accordance with anembodiment. Method 2050 may be performed by a processor in a computingdevice that implements all or portions of a DSC component. In block2052, the processor may broadcast a communication message that includesinformation advertising that a telecommunication resource in a firsttelecommunication network is available for allocation and use bywireless devices in a second telecommunication network. In block 2054,the processor may determine lease criteria parameters of a resourcelease associated with the advertised telecommunication resource. Inblock 2056, the processor may determine the network capabilities of thesecond telecommunication network. In block 2058, the processor mayselect one of a DSA Lite network configuration, DSA9 networkconfiguration, and DSAX network configuration based on the determinednetwork capability and determined lease criteria. In block 2060, theprocessor may determine configuration parameters (e.g., configurationparameters that match a specific OEM format, etc.) for one or more nodesin each of the first and second telecommunication networks based on theselected network configuration. In block 2062, the processor may sendthe determined configuration parameters to components in each of thefirst and second networks (e.g., in their respective OEM formats, etc.).

FIG. 21A illustrates various example components, operations andinformation flows in a system 2100 that is organized/configured toperform DSAFlex operations in accordance with an embodiment. FIGS. 21Band 21C are expanded views of various phases illustrated in FIG. 21A.FIG. 21B illustrates the detailed DSAFlex operations and phases in thelessee network. FIG. 21C illustrates detailed DSAFlex operations andphases in a lessor network.

FIG. 21A illustrates that the system 2100 may include a lessee networkgrouping that includes a lessee DSC 2101 component, an eNodeB 2103component, an MME 2105 component and a lessor HSS 2107 component, and alessor network grouping that includes a lessor DSC 2151 component, aneNodeB 2153 component, an MME 2155 component, a lessee HSS 2157component, and a S-GW 2159 component. The system 2100 and/or any of theabove mentioned components may be configured to perform or provideDSAFlex operations. In some embodiments, these components may beconfigured to perform DSAFlex operations in phases (e.g., initializationphase, lease allocation phase, lease execution phase, etc.).

In the examples illustrated in FIGS. 21A through 21C, the components areconfigured to perform the DSAFlex operations in four phases, whichinclude a DSC initialization phase 21001, a lease allocation phase21002, lease execution phase 21003, and a lease termination phase 21004.In some embodiments, the DSAFlex operations within each phase may beperformed in a chronologic order/sequence. In some embodiments, thephases themselves may be performed in a chronologic order/sequence. Forexample, the components may be configured so that the DSAFlex operationsassociated with the DSC initialization phase 21001 are performed beforethe operations in the lease allocation phase 21002, the operationsassociated with the lease allocation phase 21002 are performed beforethe operations in the lease execution phase 21003, etc.

In some embodiments, the components may be configured so that DSAFlexoperations that are associated with same phase (e.g., lease allocationphase, etc.) are performed at different times in different participatingnetworks. For example, in various embodiments, the components in thelessor network grouping may perform DSAFlex operations associated withthe DSC Initialization phase 21001 before, concurrent with, or after thecomponents in the lessor network perform similar or correspondingDSAFlex operations associated a corresponding DSC Initialization phase21001. Thus, while the example illustrated in FIG. 21A generally followsa chronologic sequence for the operations, it should be understood thatall or portions of the DSAFlex operations within each phase may beinterchanged, repeated, returned to, executed concurrently, eliminated,added as needed for specific implementations and/or in differentembodiments. As such, the claims should not be interpreted as requiringa particular sequence or chronological order for the performance of theDSAFlex operations or phases unless expressly recited as such in theclaims.

With reference to FIG. 21B, in the DSC initialization phase 21001, thecomponents (e.g., lessee DSC 2101 component, eNodeB 2103 component,etc.) may perform operation 2109. In operation 2109, the lessee DSC 2101component (in the lessee network) may receive detailed eNodeBconfiguration information (e.g., eNodeB registration information, etc.)from one or more eNodeB 2103 components in the lessee network. TheeNodeB configuration information may include information identifying thecells that are served or being serviced, cell types, cell areas, aneighbor list, and/or other similar information that may be collected by(or which is otherwise available to) the eNodeBs.

In the lease allocation phase 21002, the components (e.g., lessee DSC2101 component, HSS 2107 component, MME 2105 component, etc.) mayperform operations 2111 and 2113. In operation 2111, the lessee DSC 2101component may perform any or all of the operations, methods ortechniques discussed in this application to identify and select suitableeNodeB 2103 components (and/or UEs that are attached to select eNodeB2103 components). For example, in operation 2111, the lessee DSC 2101component may identify and select the suitable eNodeB 2103 component(and/or UEs that are attached to select eNodeB 2103 components) based onany combination of factors, such current congestions levels, a detectedtrigger, condition or event, an expected increase in usage, currentusage rates, or any other factor or parameter discussed in thisapplication. In addition, the lessee DSC 2101 may also identify a lesseeMME 2105 component (MME in the lessee network) that is responsible formanaging the identified/selected eNodeB 2103 components, generate acommunication message that includes information identifying the eNodeB2103 components that are in the grid (and/or a list of grids, lessorPLMN information, or other similar information), and send the generatedcommunication message to the identified lessee MME 2105. In operation2113, the MME 2105 component may receive the communication message(which identifies the selected eNodeB 2103 components) from the lesseeDSC 2101, identify the UEs that are attached to the relevant eNodeB 2103components, determine the identified UEs are suitable candidates forinter-PLMN handovers (e.g., for during or after the lease executionphase 21003, etc.), generate a inter-PLMN handover candidate list thatidentifies the UEs determined to be suitable candidates for inter-PLMNhandovers, and send the generated inter-PLMN handover candidate list tothe lessee DSC 2101 component.

In the lease execution phase 21003, the components may performoperations 2115, 2117 and 2119. In operation 2115, the lessee DSC 2101may request and receive UE subscription information from a HSS 2107component for the UEs in the inter-PLMN handover candidate list. In someembodiments, this may be accomplished via the lessee DSC 2101 componentsending a notification message to the HSS 2107 component to indicatethat a lease execution has commenced. In response, the HSS 2107component may request and receive a list of UEs (e.g., UEs included ininter-PLMN handover candidate list, a list of UEs that will be involvedin the DSAFlex operations, etc.) from the lessee DSC 2101, collect orretrieve subscription information for the UEs included in the list, andsend UE subscription information for those UEs to the lessee DSC 2101component.

In operation 2117, the lessee DSC 2101 component may generate and sendcommunication messages to the relevant eNodeB 2103 components (e.g.,eNodeBs to which the above-mentioned UEs are attached, etc.) to initiatehandover operations and transfer attached devices from lessee network tolessor network. These communication messages may include informationidentifying the candidate UEs, subscriber or subscription information,HSS information, network information, and/or other information forhanding over the candidate devices. In response to receiving thesecommunication messages, the eNodeB 2103 may perform any or all of theDSA/inter-PLMN handover operations discussed in this application (or anyhandover operation known in the art) to transfer one or more of thecandidate devices from a first network (e.g., lessee network) to asecond network (e.g., lessor network). As part of operation 2117, thevarious components may perform inter-PLMN handovers operations thatinclude sending lessee PLMN information from the lessee network to thelessor network, initiating broadcast of the PLMN information on thelessor network, configuring measurement object(s) for the lessorfrequency on the UEs selected for DSAFlex operations, etc.

In operation 2119, the MME 2105 component may generate and send statusupdate messages to the lessee DSC 2101. In some embodiments, the MME2105 component may be configured so that update messages are send foronly the UEs that were selected for DSAFlex operations and/or for whichupdated information is relevant. These status update messages may alsoinclude status information for any or all of the relevant UEs, eNodeBs,grids (e.g., grids involved in the DSAFlex operations, etc.), orcomponents that are participating in, or which are relevant to, theperformance of DSAFlex operations. For example, the status updatemessages may include updated information regarding the number of UEsthat are actively connected to the network within the grids identifiedfor DSAFlex operations, information identifying the UEs that are campedon the network within the DSAFlex grids, information identifying the UEsthat have entered or left the DSAFlex grids, etc.

In some embodiments, as part of operation 2119, the MME 2105 componentmay monitor various components, resources and conditions (e.g., UEs,eNodeBs, grids, network congestion, etc.) to collect information, andsend the collected information to the relevant components. For example,the MME 2105 component provide information regarding idle-to-connectedmode transitions (e.g., for UEs, etc.) or generate information suitablefor causing transitions (e.g., idle-to-connected mode transitions, etc.)to occur in operation 2119. In the various embodiments, all or portionsof operation 2119 may be performed continuously or repeatedly during orthroughout the lease execution phase 21003 (e.g., for the entire periodassociated with the lease execution phase 21003, until the leaseexecution phase 21003 is complete, etc.). Alternatively or in addition,operation 2119 may be performed periodically, at set time intervals, orin response to various conditions, triggers or events (e.g., eventstriggered in response to exceeding a usage limit, dropping below a usagelimit, a detected increase in usage that exceeds a threshold value, ausage decrease, a significant change in number of connected UEs, etc.).

During the lease termination phase 21004, the components may performoperations 2121 and 2123. In operation 2121, the lessee DSC 2101 mayperform various operations to cleanup lessor neighbor cells in thelessee. As part of these operations, the lessee DSC 2101 may execute anautomatic neighbor relation (ANR) table/procedure (or perform othersimilar operations) to manage the provisioning of neighbor cells. Forexample, in some embodiments, the cleanup operations may includeremoving neighbor cells that were part of the lessor network duringDSAFlex operations, adding neighbor cells that were removed or were notneighbors during DSAFlex operations (e.g., due to grid reconfigurationof cells, etc.). The performance of the cleanup operations may result ina release of resources on the lessee network and/or may includetransfers of UEs (e.g., handins, etc.) between networks. Theseoperations may also include rebalancing of resources in the effectedeNodeBs, grids, etc. In operation 2123, the lessee MME 2105 may performvarious operations to stop inter-PLMN handovers, stop updating UEinformation for the grids that were involved in DSAFlex operations,and/or other similar operations. In the various embodiments, all orportions of these operations may be performed after operation 2121 iscomplete, concurrent with or at the same time as operation 2121, and/orafter operation 2121.

FIG. 21C illustrates interactions between the components in the lessornetwork group, which includes a lessor DSC 2151, eNodeBs 2153, MME 2155,lessee HSS 2157 and S-GW 2159. In the example illustrated in FIG. 21C,some of the operations and actions in the lessor network are groupedinto categories and/or performed as groups. These groups include a firstgrouping 2191 for usage management, a second grouping 2193 in which UEsubscriber(s) may exit grids covered by the DSAFlex lease, and a thirdgrouping 2195 for congestion management of traffic on the lessornetwork. The first grouping 2191 includes operation 2191, the secondgrouping 2193 includes operation 2169, and the third grouping 2195includes operations 2171 through 2181.

FIG. 21C illustrates that the operations may also be associated withphases. For example, in the DSC initialization phase 21001, thecomponents may perform operation 2161. The components may performoperations 2163 and 2165 in lease allocation phase 21002, operations2167 through 2181 in the lease execution phase 21003, and operations2183 through 2189 in the lease termination phase 21004. While thesespecific operations are illustrated as being associated with specificphases in FIG. 21C, it should be understood that, in variousembodiments, any or all of the operations discussed below may beperformed in any of the phases 21001 through 21004.

The groupings 2191, 2193, 2195 themselves may also be associated withone or more of phases 21001 through 21004. For example, FIG. 21Cillustrates the first grouping 2191 as being associated with leaseallocation phase 21002. However, it should be understood that, invarious embodiments, the components may be configured to perform any orall of the operations in any of the groupings 2191, 2193, 2195 in any ofthe phases 21001-21004. It should also be understood that, in variousembodiments, the operations in each of the groupings 2191, 2193, 2195may be performed in different phases and/or across multiple phases. Forexample, in some embodiments, the operations in the first grouping 2191may span into the lease execution phase 21003 and/or the leasetermination phase 21004. As a further example, during any of phases21002 through 21004, a UE subscriber may leave the grid that is coveredby (or otherwise associated with) the performance of the DSAFlexoperations, which may cause the components to perform the operationsassociated with the second grouping 2193. Therefore, it should beunderstood that the components may perform any or all of the operationsassociated with one or more of the groupings 2191, 2193, 2195 and/orcease performing operations associated with one or more of the groupings2191, 2193, 2195 based on various triggers, events or conditions.

With reference to FIG. 21C, in operation 2161, the lessor DSC 2151 mayreceive eNodeB configuration details from one or more eNodeB 2153components in the lessor network (e.g., via a eNodeB registrationmessage). In operation 2163, the lessor DSC 2151 component may use thereceived eNodeB configuration details to identify and select eNodeB 2153components (and their associated resources, etc.) for participation inDSAFlex operations. The lessor DSC 2151 component may also generate aresource allocation message, and send the generated message to theselected eNodeBs 2153. In some embodiments, the lessor DSC 2151 may beconfigured to generate the resource allocation message to includeinformation regarding the lessee network eNobeB 2103 components andlessee UEs that are to participate in the DSAFlex operations. Theresource allocation message may also be generated to include PLMNinformation and/or any of the information obtained by the lessee DSC2101 (e.g., in operation 2109 discussed above, etc.). As part ofoperation 2163, the eNodeB 2153 component may receive the resourceallocation message, perform various resource allocation operations, andbroadcast information (e.g., lessee PLMN information, resource availablyinformation, etc.) so that it may be received by many participatingnetworks.

In operation 2165, the lessor DSC 2151 component may generate send aresource allocation message to an MME 2155 component. The resourceallocation message may include a list of the eNodeBs, lessee networkPLMN information, and other similar information. The list of the eNodeBs(or eNodeB list) may identify all of the suitable eNodeB 2153 componentsthat are in the grid of the lease (or lease grid). For example, theeNodeB list may include all of the eNodeBs identified in operation 2163.In addition, in operation 2165, the MME 2155 component may performvarious operations to allow or support inter-PLMN handovers (i.e., tohand UEs off from the lessee network to the lessor network) in responseto receiving the resource allocation message and/or in response toexecution of the lease.

In some embodiments, before or during the execution of the lease, thecomponents in the system may perform any or all of the operations in thefirst grouping 2191 (e.g., for usage management, management ofresources, etc.), examples of which include operations for preparinghandins from the lessee network, operations to obtain relevantinformation (e.g., PLMN information, Subscriber Profile ID (SPID)information, billing information, etc.), and operations to accomplishvarious network management tasks (e.g., allocate resources, properlybill for the allocation or usage of those resources, etc.).

In an embodiment, the components in the system may commence execution ofthe operations in the lease execution phase 21003 (i.e., operations 2167through 2181) after the completion of operation 2165 and after theoperations in the first grouping 2191 have been performed.

In some embodiments, any or all of operations in the lease executionphase 21003 may also be included as part of the third grouping 2195(e.g., for congestion management, etc.).

In operation 2067, the lessor DSC 2151 may send a resource allocationmessage to S-GW 2159, with instructions to begin providing accountingrecords for visiting UEs from the lessee network. The S-GW 2159 may sendaccounting records and details for billing to various components of thelessor network group (e.g., HSS 2157, MME 2155, DSC 2151, etc.) and/orto any component that is associated with usage or billing operations onthe lessor network. For example, in response to each UE that joins thelessor network from the lessee network for DSAFlex operations, the S-GW2159 may perform various operations (e.g., as part of operation 2168,etc.), collect billing or usage information, and send the billing/usageinformation to a charging system.

In operation 2169 (which may be included in the first group 2191, secondgroup 2193 and/or third group 2195 in various embodiments), the MME 2155component may generate and send status update message to the lessor DSC2151. In an embodiment, the status update message may include updatedstatus information for all lessee UEs that are connected/attached to theeNodeBs 2153. In an embodiment, the status update message may includeupdates for only those lessee UEs that are connected to eNodeBs 2153that are within the grids involved in DSAFlex operations. In anembodiment, the update message may include updated information for eachlessee and/or lessor UE that departed a grid involved in or associatedwith the DSAFlex operations. In an embodiment, the update message mayinclude information identifying the occurrence of a transition (e.g.,idle-to-connected mode transition, etc.). In some embodiments, the MME2155 component may be configured to cause a transition (e.g.,idle-to-connected mode transition, etc.), and report the occurrence orresult of the transition to lessor DSC 2151 component via the updatemessage.

In an embodiment, the MME 2155 component may be configured to generateand send the update message in response to determining that a lessee UEhas exited a lessor grid that is part of the DSAFlex operations. Such anexit may be caused by various reasons that include, but are not limitedto, UEs detaching from eNodeBs 2153 that are part of the grids coveredby DSAFlex operations, moving beyond service coverage provided by lessornetwork involved in DSAFlex operations, UEs powering down, handout tonetworks other than lessor network, etc.

In an embodiment, the MME 2155 component may be configured to generateand send the update message based on various additional criteria orconditions, such as based on a time period, handin rate, handouts, usagelevels, etc. For example, each time a UE depart a grid, the MME 2155 maygenerate and send an update message to lessor DSC 2151 to inform it ofthe updated status of the departing UEs.

In various embodiments, the MME 2155 component may be configured toperform operation 2169 before, during, and/or after the performance ofthe operations included in the second grouping 2195.

In operation 2171, the lessor DSC 2151 may communicate with the HSS 2157component (e.g., via UE subscription information request and responsemessages) to receive, exchange or synchronize UE subscriptioninformation. For example, the lessor DSC 2151 may request UEsubscription information from the HSS 2157 component, which in response,may generate and send lessee and/or lessor UE account, service, andsubscription details to the lessor DSC 2151. In an embodiment, the HSS2157 component may request or obtain the UE subscription informationfrom the S-GW 2159.

In an embodiment, the HSS 2157 component may request UE subscriptioninformation from the lessor DSC 2151 in operation 2171. For example, theHSS 2157 component may request updated account information from thelessor DSC 2151, which in response, may provide the HSS 2157 componentwith the information that it received in operation 2168 (if the lesseeHSS did not obtain it directly from the S-GW 2159, etc.). In anembodiment, the HSS 2157 component may request the necessary informationfrom the lessor DSC 2151, which in response, may contact the lesseenetwork to obtain the UE subscription information.

Allowing the HSS 2157 and lessor DSC 2151 components to exchange UEsubscription information enables the lessor network to prioritize theservices that it provides for the lessee and/or lessor UEs involved inDSAFlex operations. The lessor network may also select and allocateappropriate resources based on the UE information (e.g., frequencycapabilities, data rates, hardware settings, device requirements, etc.).This is especially useful if congestion management operations requirerebalancing of resources and UEs connected to the network. Thesubscription and/or service information may also be used to determinelevels of service and quality of service indicators to be met. Thisinformation is also useful for prioritizing UEs during congestionmanagement.

In operation 2173, one or more of the eNodeB 2153 components maygenerate and send one or more congestion triggers (congestion levelupdate(s)) to the lessor DSC 2151. The congestion level updates mayinclude information indicating to lessor DSC 2151 that the eNodeB 2153has reached certain limits and information indicating that they may needto be rebalanced or can no longer take on additional resources. This maybe caused by a number of reasons to include, but not limited to, excessDSAFlex handins for the eNodeB 2153 to handle, or normal lessor trafficaggregating at the eNodeB 2153, roaming of UEs that are not normallypart of the lessor or lesse networks. The result being eNodeB 2153 hasreached a set level that it notifies lessor DSC 2151 of the burden toeNodeB 2153. Upon receiving a notification from an eNodeB 2153 inoperation 2173, a lessor DSC 2151 may execute any one, some or all ofoperations 2175-2181. The lessor DSC may conduct operations to decidewhich operations will best respond to the congestion level update tocontinue to provide services to lessor network UEs and lessee networkUEs according to the terms of the DSAFlex lease.

In operation 2175, provide instructions to an eNodeB 2153 to stopbroadcasting lessee PLMN. If the congestion level reduces this may solvethe issue. Additionally, or alternatively, the lessor DSC 2151 may sendthe lessor MME 2155 instructions to rebalance the resources beinghandled by the eNodeB 2153 reporting a congestion level update. This mayinclude the lessor MME 2153 sending instructions to the eNodeB 2153 tostop broadcasting the lessee network PLMN information or to initiationother actions, such as to initiate handovers to other networks forlessor UEs or lessee UEs, initiating handovers to neighboring eNodeBs oflessor UEs and other actions to reduce the load on the eNodeB whilemaintaining services agreed to according to the terms of the DSAFlexlease.

In response to receiving the notice in operation 2175, the lessor DSC2151 may execute operation 2177. In operation 2177, eNodeBs 2153 mayconfigure measurement object(s) for the lessee frequency on lessee UEsto determine actions in preparation for alleviating congestion. As partof operation 2177, the eNodeBs 2153 may initiate handover of lessee UEsfrom specific eNodeBs 2153 that have reached a set congestion level toother eNodeBs 2153 in the lessor network, or may initiate handover oflessee UEs back to the lessee network to alleviate the congestion.

In response to receiving the notice in operation 2175, the lessor DSC2151 may execute operation 2179. In operation 2179 the lessor DSC 2151may provide a message to MME 2155 to prevent further inter-PLMNhandovers from the lessee network to specific eNodeBs 2153. This mayinclude only the congested eNodeB 2153, prevention of inter-PLMNhandovers may include other eNodeBs 2153 that are part the grid involvedin DSAFlex operations on the lessor network or to prevent all additionalinter-PLMN handovers from the lessee network.

In response to receiving the notice in operation 2175, the lessor DSC2151 may execute operation 2181. In operation 2181, lessor DSC 2151 maysend a message to eNodeB 2153 that sent the congestion level updatemessage, or any eNodeBs 2153 involved in the DSAFlex operation, withinstructions to release the lessee UE with redirection information toother eNodeBs 2153. Alternatively, the instructions may includeredirection back to lessee network of the lessee UE(s).

As mentioned above, FIGS. 21A and 21C illustrate operations 2175 through2181 as being performed in a particular order. However, it should beunderstood that operations 2175-2181 may be perform in any order. Eachoperation 2175-2181 can be executed in response to any of the otheroperations 2175-2181. Any two or more of the operations 2175-2181 may beexecuted in any sequence or at the same time. In alternativeembodiments, any one operation 2175-2181 may be executed to attempt toalleviate congestions and if it is not successful within a given periodof time or does not remedy any quality of service issues, any one ormore of the operations 2175-2181 may be executed to alleviate thecongestion or improve service parameters.

Upon expiration of the DSAFlex lease, operation 2183 may be executed. Inoperation 2183, the lessor DSC 2151 sends a message to eNodeBs 2153 sothe eNodeBs 2153 may configure measurement object(s) for the lesseefrequency on the lessee UEs. Upon configuration of the measurementobject(s) on the lessee UEs, the eNodeBs 2153 may initiate handovers ofthe lessee UEs to lessee network. Upon execution of operation 2123 onthe lessee network, the lessee DSC 2101 may send a message to lessor DSC2151 to initiate any one or more of operations 2185-2189. Alternatively,in response to the eNodeBs 2153 initiating handovers back to the lesseenetwork, the lessor DSC 2151 in operation 2185 may send instructions toinitiate a cleanup of the lessee neighbor cells in the lessor ANRtables. Alternatively, lessor DSC 2151 may execute operation 2185immediately after initiating operation 2183. As ANR table clean upoccurs, it may result in a release of resources on the lessor network.

The lessor DSC 2151 may execute operation 2187 anytime during leasetermination phase 21004 on the lessor network. In one embodiment, lessorDSC 2151 send a message to MME 2155 to initiate operation 2187, whichincludes the MME 2155 stopping inter-PLMN handovers to the lessornetwork from the lessee network. Operation 2187 may also includesstopping the update of UE information for the grid involved in DSAFlex.Stopping inter-PLMN handovers involved with the DSAFlex in the gridsinvolved will ensure no more UEs transfer from the lessee network to thelessor network. Additionally ceasing the update of UE information in thegrid involved in DSAFlex operations will ensure that any lessee UEs thatare on the lessor network do not receive lessor network information.This may include not providing lessor neighbor lists, or availableeNodeBs that were available during DSAFlex operations or any othernetwork information to the lessee UEs still on the network lessee UEsmay still be on the lessor network depending on the DSAFleximplementation, such as if there is an active session while usingDSA-Lite implementation. Alternatively, upon beginning of the leasetermination phase 21004 on the lessor network, the RAN sharing may beterminated and as such, any lessee UEs on the lessor network may havetheir sessions terminated. Having no lessor network connectioninformation, should connect to any other network available in normalnetwork connection preference as set by the UE, which generally is thelessee or UE's home network.

The lessor DSC 2151 may also send a message to lessor S-GW 2159 inoperation 2189 to signal the lessor S-GW 2159 it may stop sendingaccounting information for any lessee UEs at that time. In analternative embodiment, as each lessee UE departs the lessor network,the S-GW 2159 can notify the lessor DSC 2151 of any billing informationit has for that UE and then stop supplying the information to lessornetwork components.

Any operation that is executed by lessee DSC 2101 or lessor DSC 2151 maybe communicated to the other directly, through network components orthrough a DPC. This may trigger operations in the same network or in thenetwork receiving the communication. Examples may include, but are notlimited to, the lessor DSC 2151 initiating operation 2183 lessor DSC2151 may also communicate that this operation has begun to lessee DSC2101 such that lessee DSC 2101 may initiate operation 2121, a cleanup ofthe lessor neighbor cells in the lessee ANR table may be executed, suchthat as operation 2185, to also conduct a cleanup of the lessee neighborcells in the lessor ANR table, which in turn may be communicated tolessor DSC 2151 which may in turn initiate operation 2185.Alternatively, operations in lessee network may be triggered as actionsare completed in the lessor network, and vice versa. In one embodiment,during congestion management 2195, as UEs depart the DSAFlex grid,operation 2119 may be executed on the lessee network to update UEstatuses be triggered in the lessee network.

The network configurations illustrated in FIG. 22 is of an embodimentwhere the lessor and lessee networks both utilize a DSAX implementation.The network configurations illustrated in FIG. 23 is a of an embodimentwhere both the lessor and lessee networks utilize a DSA9 implementation.The network configurations shown in FIG. 24 is of a heterogenous DSAFlexwhere a lessor network has a DSAX implementation and the lessee networkutilizes a DSA9 implementation. The network configurations illustratedin FIG. 25 is of an embodiment where the lessor and lessee networks bothutilize a DSA-Lite implementation where the lessee has its own wirelessnetwork and infrastructure. However with DSA-Lite the lessee is notrequired to have its own infrastructure and can operate on a pure MVNO,mobile virtual network operator or the lessee can have a subset ofinfrastructure including possibly a HSS, IMS Ring, or P-GW or anycombination. The network configurations illustrated in FIG. 26 is of anembodiment utilizing a heterogenous DSAFlex where a lessor networkutilizes a DSAX implementation and a lessee network utilizes a DSA-Liteimplementation.

The DSA system may be configured to support a flexible implementationcalled DSAFlex. The components in a DSA system (i.e., DSA components)may be configured to perform DSAFlex operations that allow for severalDSA configurations that support different Original EquipmentManufacturer (OEM) that have different infrastructure implementations.

A DSAFlex architecture may be used provide the DSA functionally providedby a DSC component, which may be locally connected to a LTE wirelessnetwork.

DSAX is a DSAFlex solution that is implemented via X-interfaces. ADSAFlex solution implemented using LTE Rel 9 with RAN sharing may bereferred to in this application as DSA9. DSA-Lite is a DSAFlex solutionthat is implemented to use a pure roaming architecture.

With DSAFlex, a solution provider can enable DSA functionality whereboth networks involved with the DSA operations utilize one of DSAX,DSA9, DSA-Lite or the networks can utilize any combination of the threeas illustrated in the table below. DSAFlex may be implemented with orwithout RAN Sharing (DSA9 uses RAN Sharing, whereas DSAX and DSA-Lite donot utilize RAN Sharing).

For example with DSAFlex, DSA functionally may be implemented usingDSAX, using the DSAX interfaces and DSA9 configuration simultaneouslybetween two wireless LTE networks utilizing different OEM infrastructureequipment.

DSA9 utilizing RAN sharing can be implemented between two LTE networksboth using a DSA9 configuration.

DSA-Lite can be implemented as a standalone network or in conjunctionwith another wireless network using DSA-Lite, DSA9 or DSAX.

The table below shows the various combinations of DSA configurationspossible with DSAFlex.

RAN lessor lessee Sharing DSAX DSAX No DSAX DSA9 Yes DSAX DSAL No DSA9DSA9 Yes DSA9 DSAL No DSAL DSAL No

The advantage of using DSA9 or DSA-Lite for an existing operator is thatDSA may be implemented with functional integration of the DSC bycommunicating with just the O&M and Offline Charging System (OFCS)platforms of both the lessee and lessor networks. Additional platformsmay be integrated or modified if desired that can act as front end orliasons between the DSC and the O&M and OFCS.

DSA9 and DSA-Lite utilize the OAM to make network changes forconfiguring the lease in both the lessee and lessor networks. HoweverDSAX directly interfaces with the LTE nodes for both the lessee andlessor network utilizing a DSA Software Feature Pack (SP) enhancement tothe LTE network for both Core and RAN. The SP can also be implementedusing a distributed approach where the RAN has a localized server orsubset of the core components enabling local control at the very edge ofthe network enabling elaborate policy control functions and features tobe instilled allowing for current and future capabilities for leasemanagement with DSA.

In all configurations of DSAFlex the OEM vendor may provide assistancewith specific features for implementation based on the software load.This includes the individual details of how the features are implementedwithin the specific network provider's infrastructure, commands, and anyformatting needed to facilitate the implementation of DSA capabilityinto the wireless network.

As referenced previously, DSAFlex can be used with and without RANsharing. DSAX and DSA-Lite do not require RAN sharing. However, DSA9typically uses a RAN sharing approach, however there are configurationspossible by those in the craft where DSA9 does not require RAN sharing.

DSA-Lite may be used as an in-market roaming architecture. Thein-marketing roaming architecture for DSA-Lite may include mobilityutilizing the S10 link 2501 as illustrated in FIG. 25 and the option S10link 2601 and optional S10 link 2603 as illustrated in FIG. 26. HoweverDSA-Lite does not utilize RAN sharing or features for managed mobilityof UEs between the lessee and lessor networks. The X interface, orthrough RAN sharing capabilities it is possible to conduct mobilitymanagement between a lessee and lessor networks for an active session.DSA-Lite provides connectivity to the lessee P-GW as is done currentlyin the wireless industry for Roaming.

DSA9 generally uses RAN Sharing (as compared to DSA-Lite, whichgenerally does not). The RAN Sharing configuration that is used withDSA9 may be Multiple Operator Core Network (MOCN) architecture. DSA9 isdifferent than DSAX. For example, DSAX uses a Gateway Core Network(GWCN) and a MOCN. However if DSAX is used with a DSA9 network, then theMOCN architecture may be used by itself for such a configuration.

Connectivity for transporting traffic between the lessee and lessornetworks may be different if DSA9 is used (as compared to DSAX orDSA-Lite). With DSAX or DSA-Lite, the S-GW 2605 on the lessor networkconnects to the lessee networks P-GW 2607. In FIG. 26, this connectionis illustrated by the S8 connection 2609. Components such as securitygateways 2611 a and 2611 b may exist in the connection between the S-GW2605 and P-GW 2607. For DSA9, as illustrated in FIG. 23, the lessee MME2301 and S-GW 2303 may connect to each lessor eNodeB 2307 involved withthe lease using the connection S1-Flex As illustrated by connectionsS1-M and S1-U labeled 2305 in FIG. 23. Similarly illustrated in aheterogenous DSAFlex implementation using DSA9 and DSAX, the lessee MME2415 and S-GW 2417 may be connected to each lessor eNodeB 2421 involvedwith the lease using the connection S1-Flex illustrated as connectionsS1-M and S1-U labeled 2419 in FIG. 24.

S1-Flex is currently used in LTE Rel 9 and later releases which can beused with a network using DSA to provide the RAN Sharing betweennetworks.

The lessor network may need to have the lessee PLMN-ID transmitting onthe lessor eNodeB using SIB2 regardless of which variant of DSA is beingutilized during the lease preparation phase and duration of the leasePLMN-ID with DSAFlex.

Additionally the ability to support InterFreqHO by the UEs involved withthe lease may be needed and is a standard feature with LTE currently.

The identification of which UE should be included in the DSA lease bythe lessee is expected to be completed by the lessee network operatorthrough a change in the subscriber profile in the lessee HSS 2157 asillustrated in FIGS. 21A and 21C, or HSS 2201 in FIG. 22, HSS 2309 inFIG. 23, HSS 2401 in FIG. 24, HSS 2503 in FIG. 25, or HSS 2613 in FIG.26 as part of the lease parameters with DSAFlex.

The GIS Administrator Application (GAA), as currently implemented inDSA, may continue to craft a lease and be directly involved withanalyzing a lease with DSAFlex.

The DSCs may interface into the wireless operators Network ManagementSystem (NMS) platforms O&M with DSAFlex as illustrated by functionalconnections 2203 and 2205 in FIG. 22, functional connections 2309 and2311 in FIG. 23, functional connections 2403 and 2405 in FIG. 24,functional connections 2505 and 2507 in FIG. 25, and functionalconnections 2615 and 2617 in FIG. 26. However the interaction with theO&M platforms may involve different provisioning commands based on theindividual OEM vendor to enable the implementation of the lease for boththe lessee and lessor networks. The different command structures andfile formats needed to communicate with the lessee and lessor LTEnetworks via the DSC's may also be achieved with the use of API callsthat can be implemented directly with the O&M or through a liaisonplatform that sits between the O&M and the DSC to facilitate thiscommunication.

The Automatic Neighbor Relationships (ANR) feature on all the respectiveeNodeB's for the lease area in DSAFlex should be enabled. ANR is astandard feature implemented in LTE Rel 9. In addition to the ANRfeature, inter frequency measurements for selective eNodeB's should beenabled allowing on UEs to detect neighbor cells of the lessor or lesseenetwork operating on different frequency bands. The ANR function mayfacilitate inter frequency handovers with less UE signaling beingrequired and expediting the migration of UEs from one network toanother.

Usage information used to determine how much of the lease volume hasbeen consumed may be extracted in various ways from the lessor's OFCSplatform 2209 in FIG. 22, 2315 in FIG. 23, 2409 in FIG. 24, 2511 in FIG.25, and 2621 in FIG. 26, to include through an exposed API or a Gxinterface used for Roaming extraction illustrated by interface 2207 inFIG. 22, interfaces 2313 or 2321 in FIG. 23, interface 2407 in FIG. 24,interface 2509 in FIG. 25, and interface 2619 in FIG. 26.

The Element Management System (EMS) platform that is associated with theDSC may be implemented as a shell for the existing NMS platforms used bythe operators. The DSC EMS as illustrated by 2211 and 2213 in FIG. 22,2317 and 2319 in FIG. 23, 2411 and 2413 in FIG. 24, 2513 and 2515 inFIG. 25, and 2623 and 2625 in FIG. 26 may be integrated into the variousNMS platforms by providing the necessary MIBS when required.

DSA9 may require the following to be available within the LTE networkusing DSA9: LTE Release 9 (Rel 9); Self Optimizing Networks (SON);Automatic Neighbor List (ANR); Carrier Priority (eNodeB) feature;Mobility Load Balancing (MLB) feature; Subscriber Profile ID (SPID)feature; DSC connectivity (LTE O&M, LTE OFCS); RAN Sharing enabled;S1-Flex with X2; and Roaming Restriction Support.

DSA-Lite may require the following to be available with the LTE networkusing DSA-Lite: LTE Rel 9; Roaming Allowed; Automatic Neighbor List(ANR); Carrier Priority (eNodeB) feature; Subscriber Profile ID (SPID)feature; DSC connectivity (LTE O&M, LTE OFCS); and optional S10connectivity.

DSAX may require the following to be available on the LTE network usingDSAX: LTE Rel 9; Self Optimizing Networks (SON); Subscriber Profile ID(SPID) feature; Automatic Neighbor List (ANR); Carrier Priority (eNodeB)feature; DSC connectivity (LTE O&M, LTE OFCS or S-GW (Xs)); MME (Xm);eNodeB (Xe); HSS (Xh).

From the above lists for DSAX, DSA9 and DSA-Lite, SON, ANR, MLD, SPID,S1-Flex, Carrier Priority, and RAN sharing may be features within LTERel 9. The selection of which UEs are allowed DSA capabilities may bedefined through the HSS and/or provided by the lessor MME for visitingPLMNs.

In an embodiment, DSAX may be primary architecture for implementing DSAinto a wireless LTE network.

Reference may be made to FIG. 22 for an illustration of an embodimentwhere both the lessee and Lessor networks use a DSAX implementation.

The following provides some of the key details for the implementation ofDSA9 and/or DSA-Lite in a DSAFlex environment.

DSA9 is one of the primary configuration options for DSAFlex. Thecurrent LTE networks following 3GPP can successfully implement DSA usingDSA9 with a reduced set of functionalities that are inherent to DSAX.With DSA9 the X interfaces used in DSAX are not required and generallynot used.

Because the X interfaces for DSA9 are generally not utilized, thebehavior and execution of the lease may not be as robust or dynamic asis the case with DSAX lessee subscribers may handin and out of thelessor network using an the S1-flex connection.

DSA9 is implemented by having the DSC for the respective networkinterfacing with the O&M for the LTE network facilitating the networkconfiguration to support the lease parameters. The OEMs associated withthe LTE wireless carrier infrastructure may be needed to facilitate thecorrect commands and file formats are sent to the LTE wireless networksto enable DSA capability for the lease execution.

With DSA9, several Rel 9 features may be utilized to include SubscriberProfile ID (SPID), Carrier Priority, and Mobile Load Distribution (MLD)also referred to as Mobile Load Balancing (MLB), S1-Flex, and AutomaticNeighbor Reporting (ANR).

Reference can be made to FIG. 23 for an illustration of an embodimentwhere both the lessee and Lessor networks use a DSA9 implementation.

Initiating a lease with DSA9 the eNodeB's on the lessor network may beconnected to both the lessor and lessee networks through MOCN RANsharing with S1-Flex enabled. The use of the S1-Flex facilities theconfiguration via the O&M enabling VLANs from the lessor network to bedynamically configured at the inception of the lease through defining anIP address of the lessee MME 2301 and S-GW 2303 in FIG. 23 and MME 2415and S-GW 2417 in FIG. 24.

Additionally with DSA9 the SPID for the lessee UE may be changed toreflect the channel on the lessor network that the UE will utilize. WithDSA9 the support of active UE handovers can be augmented with MobilityLoad Balancing (MLB). MLB is a common feature used in LTE Rel 9 and thenetwork operators may utilize this feature to load balance theirnetwork. When the lease begins, lessee eNodeBs which are in the leasearea may be provisioned to have the lessor RF capacity at its disposal.

The lessee eNodeBs in the lease area may be identified using the GAA andbe configured to include in the frequency selection criteria for the RFchannel on the lessor network. Therefore, all the lessee eNodeBs whichare within the Grid Area of the lease itself as defined by the GAA maybe used.

The Carrier Priority may be changed on all the lessee eNodeBs that arein the grid area defined by the GAA. Carrier Priority may be used as theprimary method for steering lessee UEs from the lessee network to theshared RAN on the lessor Network which may operate on another carrierfrequency. Carrier Priority may affect active traffic on the lesseeeNodeB and might not affect the idle UEs attached to eNodeBs.

MLB/MLD may also be utilized to include the additional LTE channel onthe lessor network for those sites in the lease area therebyfacilitating active handins from the lessee network to lessor network.The volume of traffic for shedding from the lessee to lessor network maybe reflective of the percentage (%) the lessee desires to move to thenew network capacity or lessee can lease the value as previously definedand have the lessor channel be a priority or one of several channels toselect from.

The X2 connection needed for MLB functionality between the lessee andlessor networks is facilitated by ANR capabilities for identifyingeNodeBs which are handover candidate sites for entering and exiting thelease area. The X2 connection between the lessee eNodeBs and the lessoreNodeBs involved with the lease may be automatically configured based onANR discovery.

Therefore, X2 connectivity using the inter frequency ANR feature mayenable the source eNodeB to obtain the PCI and ECGI of a neighboringcell on a different frequency and can use these to setup a new X2interface towards this eNodeB. Additionally TNL address discovery of thecandidate eNodeB, the ID of which is known from the above ANR feature,via S1 interface where a source eNodeB sends a configuration transfermessage to request the MME for the address of the candidate eNodeB whichin turn sends it to candidate eNodeB. The candidate eNodeB responds backwith its address(es) for connectivity with the initiating/source eNodeB.

Utilizing geospatial coordination the GAA may initially provide thelessee eNodeBs with the lessor shared eNodeBs that could be consideredvalid neighbors. This may assist the ANR operations for mobility. Inaddition to the current neighbor list of the MOCN site, lessor side, maybe replicated and utilized to populate the neighbor table of the lesseeside of the MOCN site. Neighbor sites which are not in the lease areamay be barred from the ANR table which may be modified by the DSC.

With DSA9 all the subscribers UEs on the lessee network may be eligiblefor DSA capability provided they have the hardware capabilities toutilize the radio channel frequency on the lessor system, unlike inDSAX.

The SPID may be used to designate which UEs may be selected for DSAduring the lease period. The SPID for those designated UEs may bechanged for the lease period where the radio channel frequency of thelessor may be added and put into the first choice selection whichenables unique selection of specific UE's for dynamic lease management.

With DSA9, selectivity of specific UEs is not guaranteed with SPIDdesignation only since SON can override the SPID designation with alocal SPID for all UEs using the eNodeB. Therefore, all the lessee UEsmay become DSA eligible.

All the lessee eNodeBs which are within the Grid Area of the leaseitself as defined by the GAA when the lease ends may have their CarrierPriority changed to remove the radio channel that is associated with theshared eNodeB on the lessor network. In addition the MLB for the lesseenetwork for defined eNodeBs in the lease area may be modified to removethe LTE channel from the available selection criteria at the lesseenetwork.

After a defined buffer time the S1-Flex connection may be removedbetween the lessee and lessor networks.

Once the lessee UE is on the lessor network, the UE may continue toremain on the lessor network since the lessor network eNodeBs may nothave the lessee channels included as a selection of handover.

The border cell area may function differently with DSA9 as compared toDSAX and is really a buffer cell. Due to the shared eNodeB approach withDSA9 the border cells are not necessary. Instead, the eNodeBs on thelessor network which are in the lease area and border the leaseboundary/grid, are called buffer cells. The ANR list for the lessee sideof the eNodeB for those cells that are buffer cells may have theirneighbor list populated at the lease inception and periodically checkedon a regular basis to remove the exterior lessor cells from lessee useand the lessee cells may be removed from use by the lessor throughbarring in the ANR tables. This may be facilitated by the DSC.

Regarding buffer cells on the lessor network the eNodeB may have thelessee channel designed as valid choice. However at the conclusion ofthe lease, only the lessee Carrier may be included in the CarrierPriority list on the lessor network. The lessee may remove the lessorfrom the Carrier Priority list at the conclusion of the lease.Additionally at the buffer cells the ANR table which may be modified toonly include the lessee network eNodeBs.

Additionally the Emergency Blind Handover feature may be used on theborder eNodeBs to direct the lessee UE back to its home network if itstarts to lose coverage.

MLB can be also used to steer traffic from the lessor to the lesseenetwork during at the conclusion of the lease for all lessor Interiorcells. The MLB for the lessor border cells may also be adjusted toexpedite the migration of lessee UEs back to the lessee network.

Additionally, on the lessor network MLB/MLD should not be configured toinclude the lessee network radio capacity at its disposal during thelease duration for the interior cell sites. At the end of the leaseduration the lessee LTE channel may be configured in the MLB forselection with interior cell sites facilitating the lessee UEs tohandover to the lessee system reflecting the preference for the lesseenetwork channel.

If MLB is not available for use then static assignment for capacity onthe shared eNodeB may be adjusted as a method for shedding traffic.Specifically the lessee may have 50%, then moved to 40%, and so on untilit achieves 0% in sequential fashion with sufficient time to ensure thelessee user experience is maintained during and after the leaseexpiration.

The InterFreqHO message may be handled by the eNodeB of the lessornetwork and generally is not a network initiated InterFreqHO request asin DSAX through the Xe interface.

Therefore, with DSA9 the inclusion of S1-Flex with MOCN RAN Sharing, apath is available for the lessee UEs to handback to the lessee networkwhen they are outside of the lease area.

During the lease period all the eNodeBs that are within the bid area mayhave their Carrier Priority listed as only that of the lessor networkscarrier. At the conclusion of the lease all the interior cell sites forthe bid area may have their Carrier Priority modified to only includethe lessee Networks Carrier.

When the lease ends the SPID for all UEs involved with the lease mayhave their SPID changed at the lessee HSS and subsequently the lesseeMME will be informed. However with SON capability, the SPID can belocally modified via SON.

DSAX provides additional capabilities for graceful migration of UEs froma lessor network to the lessee network as compared to DSA9. Gracefulmigration may ensure that the lessee UEs are sent back in an orderlyfashion. Graceful migration may involve selecting which UEs are handedback to the lessee network first based on their service class, QoS, orBearer traffic that is being used. This can help avoid a situation inwhich there is a flood of UEs that are suddenly disconnected from alessor network as they all attempt to reconnect to a lessee network atthe end of a lease.

After the lease buffer time has expired, RAN sharing may be disabled onthe lessor network for the particular lessee. The disabling of RANsharing may force the connectivity via S1-Flex facilitating RAN sharingto be torn down. At that time all active lessees UEs on the lessornetwork may then have their session terminated in this scenario.

The removal of the S1-Flex connectivity may also inform the affectedlessee eNodeBs that the radio channel capability of the lessor networkbeing no longer available and will enable the lessee eNodeBs throughSON. The MLB/MLD preferences depending on the OEM implementation mayalso need to be adjusted when removing the lessor channel preference.

All idle UEs that are camped on lessor eNodeB(s) may reselect the lesseenetwork when the PLMN-ID of the lessee network is no longer transmittedby the lessor network.

Additionally the UEs that attempt to establish a session may no longerbe able to choose the RF channel on the lessor network after the leaseends since the PLMN-ID of the lessee network will no longer betransmitted by the lessor network.

The ability to track the lease consumption based on data consumed, timeexpiration, or both is available for usage tracking of the lease withDSA9. The consumption tracking method used for DSA9 may be differentthan that used in DSAX or DSA-Lite.

Usage Tracking with DSA9 may be done by monitoring the consumedresources. For determining consumption levels it may be necessary toextract the consumption levels for the UEs using the lessor network.However since a MOCN RAN sharing approach can be used with DSA9, theS-GW of the lessor network not required to be involved. Therefore, thelessor network may not have any knowledge of the consumption takingplace. As such with DSA9, the lessee network may report via the DSC tothe DPC the consumption of usage. The DSC of the lessee Network mayutilize the DPC to relay the traffic consumption details to the lessorDSC. The ending of the lease may still be initiated by the lessor DSC asin DSAX.

The time based approach for facilitating a lease by the lessor networkmay use a time component regardless of consumption levels. Therefore,when the lease time ends the lessor DSC may invoke the termination ofthe Lease as currently done in DSAX. This may eliminate the lessee DSC'sinvolvement with tracking usage consumption.

FIG. 24 is a diagram illustrating an example embodiment where a lessornetwork uses a DSAX implementation and a lessee network uses a DSA9implementation.

DSAFlex allows for another alternative configuration called DSA-Lite.Specifically with DSA-Lite an intra-market roaming configurationfollowing 3GPP's recommendation may be utilized. DSA-Lite howevergenerally does not utilize the X-interface as with DSAX or RAN Sharingas with DSA9.

DSA-Lite has been an integral part of the DSA architecture from theinception of DSA and uses the least amount of interaction. However therespective DSCs still interact with LTE wireless networks O&M and OFCSplatforms. Therefore, even with DSA-Lite, OEM vendor involvement may beneeded to facilitate the execution of the lease parameters.

FIG. 25 is a diagram illustrating an example embodiment where both alessor and lessee network use a DSA-Lite implementation.

With DSA-Lite the lessee UEs utilize the lessor Network in a Roamingconfiguration where the lessee PLMN is transmitted on the SIB2 for thelessor eNodeB. The lessee user traffic is directed toward the lesseeP-GW which may require a connection that has sufficient bandwidth. TheUEs may access the lessor Network if they are redirected based oncarrier preference or may need to have the use of the lessor bandincluded as a priority in the SPID.

Therefore, with DSA-Lite the lessee UE may be able to gain access to thelessor network upon detection of the PLMN-ID on the SIB2.

Mobility management is generally not supported with DSA-Lite. Therefore,in DSA-Lite active lessee UEs generally can not handover from the lesseesystem to the lessor or from the lessor to the lessee network.

The grid area which designates the lease in the DSA-Lite configurationmay not be as defined as with DSA9 or DSAX due to the lack of mobilitybetween networks. Specifically with DSA-Lite, during the lease period alessee UE may be capable of handing off to cells outside of the gridarea. The session in this case remains up. Once the session iscompleted, the normal reselection operations may take place where thelessee UE is outside of the lease area and may no longer be affordedservice from that particular lease.

When the lease ends the PLMN-ID may cease to be transmitted on the SIB2of the lessor eNodeB. After a defined time the P-GW selection for thelessee UEs may no longer include the lessee P-GW.

For comparison, the following network architectures are presented whichrepresent some of the possible configurations used with DSAFlex. In allthe architecture diagrams, only one lessee and one lessor network areshown to facilitate the concept. It is possible to have moreperturbations using more than two networks based on the various networkimplementations of DSAFlex.

FIG. 26 is a diagram illustrating an example embodiment where a lessornetwork uses a DSA-Lite implementation and a lessee network uses a DSAXimplementation, which is discussed in detail above.

The various embodiments may be implemented on a variety of mobilewireless computing devices, an example of which is illustrated in FIG.27. Specifically, FIG. 27 is a system block diagram of a mobiletransceiver device in the form of a smartphone/cell phone 2700 suitablefor use with any of the embodiments. The cell phone 2700 may include aprocessor 2701 coupled to internal memory 2702, a display 2703, and to aspeaker 2704. Additionally, the cell phone 2700 may include an antenna2705 for sending and receiving electromagnetic radiation that may beconnected to a wireless data link and/or cellular telephone transceiver2706 coupled to the processor 2701. Cell phones 2700 typically alsoinclude menu selection buttons or rocker switches 2707 for receivinguser inputs.

A typical cell phone 2700 also includes a sound encoding/decoding(CODEC) circuit 2708 which digitizes sound received from a microphoneinto data packets suitable for wireless transmission and decodesreceived sound data packets to generate analog signals that are providedto the speaker 2704 to generate sound. Also, one or more of theprocessor 2701, wireless transceiver 2706 and CODEC 2708 may include adigital signal processor (DSP) circuit (not shown separately). The cellphone 2700 may further include a ZigBee transceiver (i.e., an IEEE802.15.4 transceiver) for low-power short-range communications betweenwireless devices, or other similar communication circuitry (e.g.,circuitry implementing the Bluetooth® or WiFi protocols, etc.).

The embodiments described above, including the spectrum arbitragefunctions, may be implemented within a broadcast system on any of avariety of commercially available server devices, such as the server2200 illustrated in FIG. 28. Such a server 2800 typically includes aprocessor 2801 coupled to volatile memory 2802 and a large capacitynonvolatile memory, such as a disk drive 2803. The server 2800 may alsoinclude a floppy disc drive, compact disc (CD) or DVD disc drive 2804coupled to the processor 2801. The server 2800 may also include networkaccess ports 2806 coupled to the processor 2801 for establishing dataconnections with a network 2807, such as a local area network coupled toother communication system computers and servers.

The processors 2701, 2801, may be any programmable microprocessor,microcomputer or multiple processor chip or chips that can be configuredby software instructions (applications) to perform a variety offunctions, including the functions of the various embodiments describedbelow. In some wireless devices, multiple processors 2801 may beprovided, such as one processor dedicated to wireless communicationfunctions and one processor dedicated to running other applications.Typically, software applications may be stored in the internal memory2702, 2802, before they are accessed and loaded into the processor 2701,2801. The processor 2701, 2801 may include internal memory sufficient tostore the application software instructions. In some servers, theprocessor 2801 may include internal memory sufficient to store theapplication software instructions. In some receiver devices, the securememory may be in a separate memory chip coupled to the processor 2701.The internal memory 2702, 2802 may be a volatile or nonvolatile memory,such as flash memory, or a mixture of both. For the purposes of thisdescription, a general reference to memory refers to all memoryaccessible by the processor 2701, 2801, including internal memory 2702,2802, removable memory plugged into the device, and memory within theprocessor 2701, 2801 itself.

The foregoing method descriptions and the process flow diagrams areprovided merely as illustrative examples and are not intended to requireor imply that the steps of the various embodiments must be performed inthe order presented. As will be appreciated by one of skill in the artthe order of steps in the foregoing embodiments may be performed in anyorder. Words such as “thereafter,” “then,” “next,” etc. are not intendedto limit the order of the steps; these words are simply used to guidethe reader through the description of the methods. Further, anyreference to claim elements in the singular, for example, using thearticles “a,” “an” or “the” is not to be construed as limiting theelement to the singular.

The various illustrative logical blocks, modules, circuits, andalgorithm steps described in connection with the embodiments disclosedherein may be implemented as electronic hardware, computer software, orcombinations of both. To clearly illustrate this interchangeability ofhardware and software, various illustrative components, blocks, modules,circuits, and steps have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentinvention.

The hardware used to implement the various illustrative logics, logicalblocks, modules, and circuits described in connection with theembodiments disclosed herein may be implemented or performed with ageneral purpose processor, a digital signal processor (DPC), anapplication specific integrated circuit (ASIC), a field programmablegate array (FPGA) or other programmable logic device, discrete gate ortransistor logic, discrete hardware components, or any combinationthereof designed to perform the functions described herein. Ageneral-purpose processor may be a microprocessor, but, in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DPC and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DPC core, or any other suchconfiguration. Alternatively, some steps or methods may be performed bycircuitry that is specific to a given function.

In one or more exemplary aspects, the functions described may beimplemented in hardware, software, firmware, or any combination thereof.If implemented in software, the functions may be stored as one or moreinstructions or code on a non-transitory computer-readable medium ornon-transitory processor-readable medium. The steps of a method oralgorithm disclosed herein may be embodied in a processor-executablesoftware module which may reside on a non-transitory computer-readableor processor-readable storage medium. Non-transitory computer-readableor processor-readable storage media may be any storage media that may beaccessed by a computer or a processor. By way of example but notlimitation, such non-transitory computer-readable or processor-readablemedia may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or otheroptical disk storage, magnetic disk storage or other magnetic storagedevices, or any other medium that may be used to store desired programcode in the form of instructions or data structures and that may beaccessed by a computer. Disk and disc, as used herein, includes compactdisc (CD), laser disc, optical disc, digital versatile disc (DVD),floppy disk, and blu-ray disc where disks usually reproduce datamagnetically, while discs reproduce data optically with lasers.Combinations of the above are also included within the scope ofnon-transitory computer-readable and processor-readable media.Additionally, the operations of a method or algorithm may reside as oneor any combination or set of codes and/or instructions on anon-transitory processor-readable medium and/or computer-readablemedium, which may be incorporated into a computer program product.

The preceding description of the disclosed embodiments is provided toenable any person skilled in the art to make or use the presentinvention. Various modifications to these embodiments will be readilyapparent to those skilled in the art, and the generic principles definedherein may be applied to other embodiments without departing from thespirit or scope of the invention. Thus, the present invention is notintended to be limited to the embodiments shown herein but is to beaccorded the widest scope consistent with the following claims and theprinciples and novel features disclosed herein.

What is claimed is:
 1. A dynamic spectrum arbitrage (DSA) method,comprising broadcasting a communication message that includesinformation advertising that a telecommunication resource in a firsttelecommunication network is available for allocation and use bywireless devices in a second telecommunication network; determininglease criteria parameters of a resource lease associated with theadvertised telecommunication resource; determining network capability ofthe second telecommunication network; selecting one of a DSA Litenetwork configuration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria; determining configuration parameters for one or morenodes in each of the first and second telecommunication networks basedon the selected network configuration; and sending the determinedconfiguration parameters to components in each of the first and secondnetworks.
 2. The DSA method of claim 1, wherein: selecting one of a DSALite network configuration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria comprises selecting the DSAX network configuration; andsending the determined configuration parameters to components in each ofthe first and second networks comprises sending the determinedconfiguration parameter directly to the components in the first andsecond networks.
 3. The DSA method of claim 1, wherein sending thedetermined configuration parameter directly to the components in thefirst and second networks comprises: sending configuration parameters toan eNodeB via an Xe interface; and sending configuration parameters toan MME component via an Xm interface.
 4. The DSA method of claim 1,wherein: selecting one of a DSA Lite network configuration, DSA9 networkconfiguration, and DSAX network configuration based on the determinednetwork capability and determined lease criteria comprises selecting theDSA Lite network configuration or the DSA9 network configuration; andsending the determined configuration parameters to components in each ofthe first and second networks comprises sending the determinedconfiguration parameters to an O&M component in each of the first andsecond networks.
 5. The DSA method of claim 1, wherein determiningconfiguration parameters for one or more nodes in each of the first andsecond telecommunication networks based on the selected networkconfiguration comprises: determining configuration parameters that matcha specific OEM format.
 6. The DSA method of claim 4, wherein sending thedetermined configuration parameters to components in each of the firstand second networks comprises sending the parameters in the specific OEMformat.
 7. The DSA method of claim 1, further comprising: dynamicallyselecting an interface based on the determined network capability. 8.The DSA method of claim 1, further comprising: routing traffic todestination components based on the network configuration of the secondnetwork;
 9. The DSA method of claim 1, further comprising: receiving ina dynamic spectrum controller (DSC) processor a list of resources thatare available for bidding via a communication link to a dynamic spectrumpolicy controller (DPC) that includes a DPC processor; generating a bidrequest message that includes information suitable for bidding on aresource identified in the received list of resources; and sending thegenerated bid request message to the DPC via the communication link. 10.The DSA method of claim 9, further comprising starting by the DPCprocessor a bid timer; receiving in the DPC processor the bid requestmessage from the DSC via the communication link; determining whether thebid request message is valid; sending a bid accept message to the DSCvia the communication link in response to determining that the bid isvalid; determining whether the bid timer has expired; determiningwhether the DSC is a winner bidder that is to be allocated the resourcebased on information included in the bid request message in response todetermining that the bid request message is valid and that the bid timerhas expired; and sending a bid won message to the DSC via thecommunication link in response to determining that the DSC is the winnerbidder.
 11. A server computing device, comprising: a processorconfigured with processor executable instructions to perform operationscomprising: broadcasting a communication message that includesinformation advertising that a telecommunication resource in a firsttelecommunication network is available for allocation and use bywireless devices in a second telecommunication network; determininglease criteria parameters of a resource lease associated with theadvertised telecommunication resource; determining network capability ofthe second telecommunication network; selecting one of a DSA Litenetwork configuration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria; determining configuration parameters for one or morenodes in each of the first and second telecommunication networks basedon the selected network configuration; and sending the determinedconfiguration parameters to components in each of the first and secondnetworks.
 12. The computing device of claim 11, wherein the processor isconfigured with processor executable instructions to perform operationssuch that: selecting one of a DSA Lite network configuration, DSA9network configuration, and DSAX network configuration based on thedetermined network capability and determined lease criteria comprisesselecting the DSAX network configuration; and sending the determinedconfiguration parameters to components in each of the first and secondnetworks comprises sending the determined configuration parameterdirectly to the components in the first and second networks.
 13. Thecomputing device of claim 11, wherein the processor is configured withprocessor executable instructions to perform operations such thatsending the determined configuration parameter directly to thecomponents in the first and second networks comprises: sendingconfiguration parameters to an eNodeB via an Xe interface; and sendingconfiguration parameters to an MME component via an Xm interface. 14.The computing device of claim 11, wherein the processor is configuredwith processor executable instructions to perform operations such that:selecting one of a DSA Lite network configuration, DSA9 networkconfiguration, and DSAX network configuration based on the determinednetwork capability and determined lease criteria comprises selecting theDSA Lite network configuration or the DSA9 network configuration; andsending the determined configuration parameters to components in each ofthe first and second networks comprises sending the determinedconfiguration parameters to an O&M component in each of the first andsecond networks.
 15. The computing device of claim 11, wherein theprocessor is configured with processor executable instructions toperform operations such that determining configuration parameters forone or more nodes in each of the first and second telecommunicationnetworks based on the selected network configuration comprises:determining configuration parameters that match a specific OEM format.16. The computing device of claim 14, wherein the processor isconfigured with processor executable instructions to perform operationssuch that sending the determined configuration parameters to componentsin each of the first and second networks comprises sending theparameters in the specific OEM format.
 17. The computing device of claim11, wherein the processor is configured with processor executableinstructions to perform operations further comprising: dynamicallyselecting an interface based on the determined network capability. 18.The computing device of claim 11, wherein the processor is configuredwith processor executable instructions to perform operations furthercomprising: routing traffic to destination components based on thenetwork configuration of the second network;
 19. The computing device ofclaim 11, wherein the processor is configured with processor executableinstructions to perform operations further comprising: receiving a listof resources that are available for bidding via a communication link toa dynamic spectrum policy controller (DPC) that includes a DPCprocessor; generating a bid request message that includes informationsuitable for bidding on a resource identified in the received list ofresources; and sending the generated bid request message to the DPC viathe communication link.
 20. The computing device of claim 19, whereinthe processor is configured with processor executable instructions toperform operations further comprising: starting by the DPC processor abid timer; receiving in the DPC processor the bid request message from aDSC via the communication link; determining whether the bid requestmessage is valid; sending a bid accept message to the DSC via thecommunication link in response to deter mining that the bid is valid;determining whether the bid timer has expired; determining whether theDSC is a winner bidder that is to be allocated the resource based oninformation included in the bid request message in response todetermining that the bid request message is valid and that the bid timerhas expired; and sending a bid won message to the DSC via thecommunication link in response to determining that the DSC is the winnerbidder.
 21. A non-transitory computer readable storage medium havingstored thereon processor-executable software instructions configured tocause a processor to perform operations comprising: broadcasting acommunication message that includes information advertising that atelecommunication resource in a first telecommunication network isavailable for allocation and use by wireless devices in a secondtelecommunication network; determining lease criteria parameters of aresource lease associated with the advertised telecommunicationresource; determining network capability of the second telecommunicationnetwork; selecting one of a DSA Lite network configuration, DSA9 networkconfiguration, and DSAX network configuration based on the determinednetwork capability and determined lease criteria; determiningconfiguration parameters for one or more nodes in each of the first andsecond telecommunication networks based on the selected networkconfiguration; and sending the determined configuration parameters tocomponents in each of the first and second networks.
 22. Thenon-transitory computer readable storage medium of claim 21, wherein thestored processor-executable software instructions are configured tocause the mobile device processor to perform operations such that:selecting one of a DSA Lite network configuration, DSA9 networkconfiguration, and DSAX network configuration based on the determinednetwork capability and determined lease criteria comprises selecting theDSAX network configuration; and sending the determined configurationparameters to components in each of the first and second networkscomprises sending the determined configuration parameter directly to thecomponents in the first and second networks.
 23. The non-transitorycomputer readable storage medium of claim 21, wherein the storedprocessor-executable software instructions are configured to cause themobile device processor to perform operations sending the determinedconfiguration parameter directly to the components in the first andsecond networks comprises: sending configuration parameters to an eNodeBvia an Xe interface; and sending configuration parameters to an MMEcomponent via an Xm interface.
 24. The non-transitory computer readablestorage medium of claim 21, wherein the stored processor-executablesoftware instructions are configured to cause the mobile deviceprocessor to perform operations such that: selecting one of a DSA Litenetwork configuration, DSA9 network configuration, and DSAX networkconfiguration based on the determined network capability and determinedlease criteria comprises selecting the DSA Lite network configuration orthe DSA9 network configuration; and sending the determined configurationparameters to components in each of the first and second networkscomprises sending the determined configuration parameters to an O&Mcomponent in each of the first and second networks.
 25. Thenon-transitory computer readable storage medium of claim 21, wherein thestored processor-executable software instructions are configured tocause the mobile device processor to perform operations such thatdetermining configuration parameters for one or more nodes in each ofthe first and second telecommunication networks based on the selectednetwork configuration comprises: determining configuration parametersthat match a specific OEM format.
 26. The non-transitory computerreadable storage medium of claim 24, wherein the storedprocessor-executable software instructions are configured to cause themobile device processor to perform operations such that sending thedetermined configuration parameters to components in each of the firstand second networks comprises sending the parameters in the specific OEMformat.
 27. The non-transitory computer readable storage medium of claim21, wherein the stored processor-executable software instructions areconfigured to cause the mobile device processor to perform operationsfurther comprising: dynamically selecting an interface based on thedetermined network capability.
 28. The non-transitory computer readablestorage medium of claim 21, wherein the stored processor-executablesoftware instructions are configured to cause the mobile deviceprocessor to perform operations further comprising: routing traffic todestination components based on the network configuration of the secondnetwork;
 29. The non-transitory computer readable storage medium ofclaim 21, wherein the stored processor-executable software instructionsare configured to cause the mobile device processor to performoperations further comprising: receiving a list of resources that areavailable for bidding via a communication link to a dynamic spectrumpolicy controller (DPC) that includes a DPC processor; generating a bidrequest message that includes information suitable for bidding on aresource identified in the received list of resources; and sending thegenerated bid request message to the DPC via the communication link. 30.The non-transitory computer readable storage medium of claim 29, whereinthe stored processor-executable software instructions are configured tocause the mobile device processor to perform operations furthercomprising starting by the DPC processor a bid timer; receiving in theDPC processor the bid request message from a DSC via the communicationlink; determining whether the bid request message is valid; sending abid accept message to the DSC via the communication link in response todeter mining that the bid is valid; determining whether the bid timerhas expired; determining whether the DSC is a winner bidder that is tobe allocated the resource based on information included in the bidrequest message in response to determining that the bid request messageis valid and that the bid timer has expired; and sending a bid wonmessage to the DSC via the communication link in response to determiningthat the DSC is the winner bidder.